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A todos los que, 

con su apoyo y paciencia 
han hecho posible este libro: 
las dos Blancas, Arancha, 
Amaya, Paco y Ricardo..., 
entre otros. 


INTRODUCCION 


STE libro es una introducción a los lenguajes que se sue- 
len utilizar para programar las aplicaciones informáticas 
desarrolladas en las áreas que los expertos incluyen en el 
término genérico de Inteligencia Artificial (1.A.) 


Lo primero que habría que preguntar es qué se entien- 
de por I.A. Según Henry Bergson (L'Evolution Créatrice, 
1907), «Inteligencia... es la facultad de construir objetos 
artificiales, especialmente herramientas, para fabricar 
herramientas». En el ámbito de la informática esto supon- 
dría no sólo crear sistemas (herramientas del hombre, al fin y al cabo) para 
procesar los datos o las informaciones, sino «sistemas que construyan siste- 
mas». 


Es decir, que, siguiendo esta línea de razonamiento, deberíamos enten- 
der que los «sistemas informáticos» aportan «inteligencia» cuando inclu- 
yen en alguna medida esa capacidad de evolución para generar diversos 
sistemas, adecuados a las distintas necesidades. Algunas de las aplicacio- 
nes que se consideran en el ámbito de la 1.A. disponen de características 
de este estilo; especialmente los sistemas de monitorización y los sistemas 
expertos (sistemas de toma de decisiones variadas ante situaciones «nue- 
vas» a partir de datos preexistentes). 


Sin embargo, se acepta que son «inteligentes» otros procesos en que 
esta capacidad «creativa» no es tan evidente: en un sistema de procesa- 
miento de palabra o en uno de visión artificial, priman las cualidades que 
hacen referencia a la posibilidad de evaluación de contextos complejos, al 
procesamiento rápido de gran cantidad de datos y a la flexibilidad de 
adaptación al entorno en el que se realizan los cómputos. 


Quizá en estos casos fuera más adecuada la idea de Turing sobre la de- 
finición de «inteligencia» cuando proponía como prueba de un «sistema in- 
teligente» la consistente en definir como tal a una máquina o sistema si su 
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«comportamiento» parecía semejante al humano a un observador exterior 
a los procesos que se realizan. 

En cualquier caso, no es fácil abordar la problemática total de la 1.A. 
de un solo «vistazo». En esta colección de libros han aparecido varios vo- 
lúmenes (y algún otro está pendiente de publicación) sobre áreas especí- 
ficas de la 1.A. Todas ellas tienen en común, sin embargo, algunas técnicas 
básicas y los lenguajes informáticos en que se programan. El objeto del pre- 
sente libro es estudiar, precisamente, estos lenguajes de programación de 
las aplicaciones de la IA. 

Se intenta obtener tres metas en este libro, bien que al nivel básico que 
corresponde al espacio disponible y al destino de la colección (sin que por 
ello deje de ser el trabajo efectuado absolutamente riguroso y desarrolla- 
do con todo nuestro interés): presentación general de los lenguajes utili- 
zados en I.A. y sus características (donde subyacen, en cierto modo, las ca- 
racterísticas generales que debe tener un sistema para ser incluido en el 
ámbito de la 1.A.); descripción de dos de los lenguajes más utilizados (des- 
cripción básica pero suficiente, según entendemos, para poder llegar a pro- 
gramar en cualquiera de los dos); presentación de las técnicas elementa- 
les de programación que con estos lenguajes se desarrollan, y que subya- 
cen en todas las aplicaciones de 1.A. 

En el primer capítulo se introduce la problemática general de progra- 
mación para la I1.A., en el segundo se explica la programación básica en 
LISP (“uno de los más antiguos y uno de los más modernos lenguajes de 
programación”) y en el tercero la programación en PROLOG (“el lengua- 
je de programación del año 2000”). 

Como se incluyen numerosos ejemplos entendemos que sería útil se- 
guir la lectura estando delante del crdenador (¡encendido!); pero esto no 
es imprescindible para entender los conceptos expuestos y obtener una vi- 
sión clara de los «lenguajes de la 1.A.». 


LOS LENGUAJES DE LA 
INTELIGENCIA ARTIFICIAL 


¿SON NECESARIOS 
LENGUAJES ESPECIFICOS 
PARA LA INTELIGENCIA ARTIFICIAL? 


A primera pregunta que surge cuando se piensa en «los 
lenguajes de la 1.A.» es: ¿realmente es necesario disponer 
de lenguajes específicos para programar tareas de las que 
solemos incluir en la 1.A.? 


La respuesta a esta pregunta es, según la mayoría de 
los expertos, que no es necesario disponer de ningún len- 
guaje específico para programar 1.A., pero que es muy con- 
veniente. En efecto, tal como hemos comentado, básica- 
=== mente, la 1.A. es un modo de enfocar los problemas, unas 
técnicas específicas de desarrollo de la programación, unos procesos con- 
cretos que con estas técnicas y con otros enfoques se pueden abordar, pero 
en informática, al fin y al cabo. Se puede decir que casi en el cien por cien 
de los casos es posible programar «cualquier cosa en cualquier lenguaje»; 
sin embargo, nadie duda que hay lenguajes especialmente aptos para cier- 
tas tareas y otros para otras distintas. 


De hecho, existen procesos y sistemas que deben incluirse en el ámbi- 
to de la I.A. y que están programados en lenguajes diversos. En concreto, 
al final de este capítulo, y como contraste con el resto de temas desarro- 
llados en todo el libro, se presentan varias experiencias típicamente de LA. 
(un «generador» de sistemas expertos, un sistema de interpretación en con- 
tinuo de datos provenientes de sensores) escritos en otros lenguajes (For- 
tran, Pascal) distintos de los «típicos de Inteligencia Artificial» que se des- 
criben en estas páginas. 


Como veremos, para representar adecuadamente el conocimiento y 
para operar con él (en los sistemas expertos), para representar y manejar 
eficientemente los fragmentos de lenguaje natural (en los sistemas de in- 
terface con el usuario o en los procesos de lenguaje natural), para alma- 
cenar y tratar con éxito la información gráfica, etc., es útil utilizar al- 
gún(os) lenguaje(s) con características especiales: incluso, dependiendo 
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del tipo de aplicación a abordar, será mejor utilizar uno u otro de los «len- 
guajes de la 1.A.» disponibles. 

Aportemos un argumento más a nuestro razonamiento subrayando 
cómo las empresas comerciales dedicadas a este área de la informática 
han tomado tradicionalmente el camino de la especialización (y no el de 
la generalización), llegando a construir máquinas específicas para los pro- 
cesos de I.A. De esta idea han surgido las máquinas LISP y por este cami- 
no discurre, asimismo, el proyecto japonés de los «ordenadores de la quin- 
ta generación». 

En efecto, la idea de construir máquinas específicas que se adecuaran 
a las estructuras que usualmente aparecen en los problemas de I.A. es muy 
antigua; ya en 1960 Newel y Tonge' escribieron: «La última versión dispo- 
nible del lenguaje IPL (el IPL-VI) ha sido escrita como una propuesta de 
conjunto de instrucciones para un ordenador que ejecutaría directamente 
un lenguaje de proceso de la información y, por tanto, conseguiría una eje- 
cución muchísimo más rápida que con la realización interpretativa dispo- 
nible actualmente sobre máquinas convencionales.» 

Las máquinas específicas para los procesos de I.A. se han desarrollado 
en dos direcciones distintas: como máquinas LISP y como ordenadores de 
proceso paralelo. 

Las máquinas LISP son aquellas concebidas para implementar directa- 
mente las operaciones de proceso de listas y las funciones de manejo del 
almacenamiento de información proporcionadas por los intérpretes de 
LISP. Estas máquinas suelen disponer, además, de pantallas de presenta- 
ción de alta calidad para facilitar el entorno de programación adecuado a 
estas tareas, con varias «ventanas» donde se examinan simultáneamente 
varios aspectos de un mismo proceso. En esta línea se han desarrollado nu- 
merosos proyectos y hay varias compañías dedicadas básicamente a esta 
actividad: Symbolics es una de las principales compañías suministradoras 
de productos de Inteligencia Artificial (69 millones de dólares en 1985, 
1.250 máquinas LISP instaladas); y Lisp Machine Inc. (LMI). Estas dos com- 
pañías, junto con Rank Xerox (líder mundial por número de máquinas 
LISP instaladas), y Texas Instruments (que trabaja con licencia LMI), tie- 
nen monopolizado prácticamente el mercado mundial de máquinas LISP. 
Actualmente Sperry está introduciéndose con fuerza en este área y última- 
mente la misma IBM declara su interés por abordar este tipo de aplicacio- 
nes. 

En la dirección de construir ordenadores de proceso paralelo (multi- 
procesadores) se mueve, por otro lado, el proyecto de «los ordenadores 
de la quinta generación» (además de que, en este proyecto, se haya toma- 
do como base el lenguaje PROLOG y no el LISP). 


1. Newel , A., y Tonge, F. M.: «An Introduction to Information Processing Language V». 
Communications of the ACM. Vol. 3, págs. 205-211, 1960. 
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Sin embargo, la realidad del mercado informático actual con precios 
cada vez más bajos para máquinas con enormes potencias crecientes día 
a día e, incluso, la presión de algunas compañías (encabezadas por la pro- 
pia IBM, según parece) hacen que haya que considerar como una opción 
muy válida la utilización de máquinas convencionales con eficaces intér- 
pretes de lenguajes específicos de Inteligencia Artificial y sofisticados en- 
tornos de programación (con ventanas, menús, etc., y manejados desde ra- 
tones o pantallas táctiles). 


CARACTERÍSTICAS DE LOS LENGUAJES 
PARA LA INTELIGENCIA ARTIFICIAL 


Aceptando, por tanto, que es muy útil utilizar algunos lenguajes espe- 
cíficos para resolver los problemas de I.A., surge la pregunta de cuáles son 
las características que deben tener los lenguajes que han de ser utilizados 
para la implementación de sistemas en el área de IA. 

La respuesta se puede dividir en dos partes (según E. Rich, pág. 390, 
obra citada): 


— Las características que son importantes para la construcción de di- 
versos tipos de sistemas informáticos complejos, incluyendo los de I.A. 

- Las características que son particularmente importantes en la cons- 
trucción de sistemas de I.A. debido a las propiedades especiales de dichos 
sistemas. 


Consideremos primero las características importantes que debe poseer 
un buen lenguaje utilizado para la construcción de prácticamente cual- 
quier gran sistema: 


- Variedad de tipos de datos para describir los diferentes tipos de in- 
formación necesarios en un sistema grande. 

— Habilidad para descomponer el sistema en unidades pequeñas y 
claras, de manera que resulte relativamente fácil cambiar una parte del sis- 
tema sin tocar su totalidad. 

— Estructuras de control flexible que faciliten la recursión y la des- 
composición paralela del sistema. 

— Habilidad de comunicarse con el sistema interactivamente, para 
el desarrollo de programas y para obtener una efectividad máxima en el 
uso del sistema sobre el que se trabaja. 

— Habilidad de producir código eficiente, de manera que el funcio- 
namiento del sistema sea aceptable. 


Resulta interesante constatar que, a pesar de que todas estas caracte- 
rísticas son importantes hoy en día para cualquier gran sistema, fueron de- 
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tectadas como necesarias y desarrolladas en lenguajes de 1.A. Por ejemplo, 
LISP fue, durante mucho tiempo, uno de los pocos lenguajes interactivos 
de gran aceptación, y se utilizó como una base para el desarrollo de téc- 
nicas de programación interactiva (Sandewall, 1978). 

Además de estas características generales tan deseables, hay otras cuya 
importancia en el desarrollo de sistemas de 1.A. es hoy en día reconocida, 
a pesar de que no han resultado útiles en otros contextos. Estas caracte- 
rísticas incluyen: 


— Herramientas especializadas para la manipulación de listas, ya que 
éstas son una estructura básica utilizada en todos los programas de I.A. 

— Posibilidad de hacer ligaduras pospuestas (late binding) para informa- 
ciones como el tamaño de una estructura de datos o el tipo de objeto con el 
que se va a operar. En muchos programas de 1.A. no es posible determinar es- 
tos elementos de otra manera que no sea «al vuelo», mientras el programa 
se está ejecutando. Por ejemplo, al construir una red semántica, normal- 
mente no se sabrá con anticipación cuántos arcos emergerán de cada 
nodo. 

— Facilidades para casar diseños /pattern matching) en la indentifica- 
ción de datos y determinación del control. Estas facilidades para datos son 
una parte importante en el uso de grandes bases de conocimientos. La fa- 
cilidad de «pattern matching» para control es básica en la ejecución y pro- 
ducción de sistemas. 

— Facilidades para realizar cierto tipo de deducciones automáticas y 
para el almacenamiento y manejo de una base de datos de aserciones que 
forman la base para las deducciones. 

— Herramientas para la construcción de estructuras de conocimiento 
complejas, como, por ejemplo, marcos (frames), de manera que puedan 
ser agrupados y accedidos con una sola unidad ciertos bloques de informa- 
ción. 

— Mecanismos mediante los cuales el programador puede introducir 
conocimientos adicionales que pueden ser utilizados por el sistema para 
enfocar su atención donde la rentabilidad parece que va a ser más alta. 

— Estructuras de control que facilitan un proceso orientado hacia el 
objetivo en el proceso de arriba a abajo (top-down) junto con otro más con- 
vencional orientado hacia los datos (proceso de abajo a arriba) (bottom-up). 

— La habilidad de mezclar procedimientos y estructuras de datos de- 
clarativos del modo más conveniente a la tarea en particular que se quie- 
re realizar. 


12 


ALGUNOS LENGUAJES CONCRETOS 


No existe ningún lenguaje que cumpla todas las características antes in- 
dicadas, sino que en alguno de ellos se pone especial énfasis en un aspec- 
to concreto (en detrimento de otros) y en otros lenguajes se potencian 
otras cualidades. 

Por otro lado, hay que señalar que la pléyade de lenguajes de progra- 
mación existente en informática en general se convierte en una verdadera 
constelación cuando nos atenemos al área de la Inteligencia Artificial, 
como consecuencia lógica del enorme auge que esta materia ha experi- 
mentado en los últimos dos o tres lustros. 

En efecto, entre los lenguajes básicos disponibles, sus diferentes dialec- 
tos y los entornos diversos de programación que engloban uno o varios de 
los anteriores (y los modifican y mejoran, en ocasiones) se pueden contar 
varias decenas de posibilidades para el usuario. 

Uno de los más antiguos lenguajes de programación diseñados especí- 
ficamente para aplicaciones de I.A. es IPL. De él derivó LISP, en la misma 
línea de lenguajes concebidos específicamente para el proceso de listas. 

Posteriormente, a partir del año 1970, se desarrolló una segunda gene- 
ración de lenguajes para la Inteligencia Artificial: 


a) Por un lado, aparecieron numerosas versiones (e implementacio- 
nes específicas en máquinas) del LISP: FRANZLISP, INTERLISP, UCILISP, 
CMULISP, etc., y el COMMONLISP, que ha tratado de ser un estándar uni- 
ficador de todos los dialectos existentes. 

b) Por otro lado, se desarrolló el PROLOG (a partir de 1973, en la Uni- 
versidad de Luminy, Marsella) y se han establecido posteriormente varias 
versiones e implementaciones de él. 

c) Del LISP han derivado, asimismo, otros lenguajes como el PLAN- 
NER (del cual, a su vez, ha derivado CONNIVER), SMALLTALK, KRL, etc. 

d) En otra dirección diferente, aunque derivado de LISP también, ha 
surgido un lenguaje de proceso de listas y gráficos que es el LOGO); utili- 
zado básicamente en aplicaciones educativas. 


Los últimos desarrollos en esta área a partir del año 1980 aproximada- 
mente (algunos de los más recientes en fase de experimentación) se diri- 
gen hacia la investigación de entornos únicos que engloben varios de los 
lenguajes antes indicados y hacia la creación de lenguajes de programa- 
ción híbridos donde se combinan varias de las técnicas desarrolladas óp- 
timamente en otros sistemas: entornos KEE, LOOPS, etc., y, más moder- 
namente, COMMONLOG, VULCAN, etc. 
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Independientemente de la genealogía de los lenguajes de programación 
utilizados para la I.A., es útil considerar los diferentes grupos en que se 
pueden reunir, en función de los modelos de representación del conoci- 
miento y de computación utilizados. En efecto, los lenguajes PROLOG y 
DUCK se utilizan básicamente para la programación lógica; SMALLTALK 
y FLAVORS en la programación orientada al objeto; OPS5 y EXPERT en la 
programación basada en sistemas de producción y, en fin, LOOPS y KEE 
combinan varios paradigmas y deben ser considerados sistemas híbridos. 


PROLOG SMALLTALK OPS5 


DUCK FLAVORS EXPERT 
QUTE 


Fig. 2. Los lenguajes usados en 1.A., según el modelo de representación del cono- 
cimiento utilizado. 


En las páginas siguientes hacemos una breve presentación de algunos 
de los lenguajes más extendidos, dejando para los capítulos posteriores el 
análisis más profundo de los lenguajes básicos utilizados en las aplicacio- 
nes de I.A.: LISP (cap. 2) y PROLOG (cap. 3). 


IPL 


Uno de los primeros lenguajes diseñados específicamente para aplica- 
ciones de IA. fue el IPL (Information Processing Language) [Newell, 
1960]. Existe en la actualidad toda una serie de lenguajes IPL, de los cua- 
les el IPL V ha sido el último en ser desarrollado. El principal objetivo de 
IPL fue el proceso de listas. El lenguaje en sí recordaba más a un lenguaje 
de máquina que a uno de alto nivel, como los que se usan actualmente. 
En la figura 3 se muestra un ejemplo de un programa IPL V. El programa 
considera un símbolo y una estructura de lista que representa un árbol, y 
comprueba si el símbolo existe o no en el árbol. 


El IPL no está en uso actualmente. Ha sido completamente reemplaza- 
do por lenguajes de alto nivel como LISP, pero es interesante porque cons- 
tituyó la base del desarrollo de los lenguajes de 1.A. 
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E 


Desplaza WO y mueve el símb. a com- 
probar a WO. 

Localiza la próxima celdilla (cell) del ár- 
bol. 

Si no hay más celdilla sale con H5+. 
Da entrada al símb. en la siguiente cel- 
dilla de la lista. 

Da entrada al símb. a comprobar. 
Comprueba si los símb. son iguales. 

Si son iguales sale con H5+. 

Desecha la referencia de la lista, saca 
WO. 

Vuelve a dar entrada al símb. de la lista. 
Comprueba si es local. 

Si no es local continúa a través de la lis- 
ta. 

Da entrada al símb. de la lista otra vez. 
Comprueba si terminan los datos de 
nombre. 

Si es el final de los datos continúa a tra- 
vés de la lista. 

Si no es el final de los datos, da nombre 
a una sublista. 

Da entrada al símb. a comprobar. 
Aplica este proceso a la sublista. 

Si se encuentra en la sublista, sale con 
H5+. 


Fig. 3. 


PLANNER 


PLANNER (Hewitt, 1971) es un lenguaje construido sobre LISP y dise- 
ñado para representar tanto la forma tradicional de razonar (hacia adelan- 
te) como la orientada al objetivo (hacia atrás). Los programas en PLAN- 
NER consisten en dos tipos de enunciados: 


— Afirmaciones, las cuales simplemente exponen un hecho. 
— Teoremas, los cuales describen cómo se puede inferir un hecho nue- 
vo a partir de uno conocido. 


A continuación hay ejemplos de los tipos de conocimiento que pueden 
ser representados por afirmaciones en PLANNER: 
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Hay tres clases de teoremas que pueden encontrarse en un programa 
PLANNER: 


— Teoremas consecuentes que describen razonamiento orientado ha- 
cia atrás o hacia el objetivo. Un ejemplo es: 


Este teorema dice que si se quiere demostrar que X es parte de Z, se 
puede hacer encontrando una Y donde X es parte de Y e Y es parte de Z. 


— Teoremas antecedentes, que describen razonamiento hacia adelan- 
te, hacia los datos. 
Ejemplo de un teorema antecedente: 


Este teorema dice que si se ha demostrado que X es parte de Y, enton- 
ces se buscan nuevas relaciones entre las partes que estén implicadas por 
ésta. Para hacerlo, se mira si hay algún valor Z donde Y es parte de Z. Si 
se encuentra alguno, concluir que X es parte de Z y añadir el hecho al con- 
junto de afirmaciones utilizables. 


— Borrado de teoremas, elimina afirmaciones de la base de datos. 


El lenguaje PLANNER nunca fue completado, pero sí un subconjunto 
de él, el micro-PLANNER. Varios programas de resolución de problemas 
se basaron en este subconjunto. 

Una de las dificultades principales que aparecieron con PLANNER fue 
que el único modo de estructura de control disponible era retroceder el 
camino (backtracking) y este proceso era automático en vez de controlado 
por el programador. Esta restricción resultó ser un gran inconveniente y 
producía una disminución de eficiencia. Como remedio se construyó un 
nuevo lenguaje, el CONNIVER (Sussman, 1972). Un programador de CON- 
NIVER puede explícitamente dirigir el control del flujo del programa. 
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KRL 


KRL (Bobrow, 1977) es un lenguaje construido sobre INTERLISP y que 
facilita la representación de conocimientos en marcos de discernimiento 
(frame structures). El desarrollo de este lenguaje fue motivado por los si- 
guientes supuestos sobre representación de conocimientos y por la nece- 
sidad de desarrollar los programas que los utilicen: 


— Los conocimientos deben ser organizados alrededor de entidades 
conceptuales con descripciones y procedimientos asociados. 


— Una descripción debe representar conocimientos parciales sobre 
una entidad y acomodar descriptores múltiples, los cuales pueden descri- 
bir la entidad asociada desde diferentes puntos de vista. 


— Un método importante de descripción es la comparación de una 
cantidad conocida, con especificaciones adicionales del ejemplo descrito, 
con respecto al prototipo. 


— El razonamiento es dominado por un proceso de reconocimiento 
por el cual son comparados nuevos objetos y sucesos con conjuntos de pro- 
totipos esperados, y en los cuales se ligan (por medio de una clave) a estos 
prototipos ciertas estrategias de razonamiento especializado. 


[Viaje UNIT Abstracto 
<SELF (un Suceso) > 
<modo (OR Avión Auto Bus)> 
<destino (una Ciudad)>] 


[Visita UNIT Especialización 
<SELF (un ContactoSocial) > 
<visitante (una Persona) > 
<visitados (GrupoDe (una Persona))>] 


[Suceso137 UNIT individuo 
<SELF ((una visita con 
visitante = Jaime 
visitador = (Artículo Juan María)) 


(un viaje con 
destino = San Sebastián 
modo = Avión)|>] 


Fig. 4. Tres unidades (UNIT's) en KRL. 
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— Los programas inteligentes requerirán procesos activos múltiples 
con horarios explícitos proporcionados por el usuario y heurísticas de asig- 
nación de recursos. 


— La información debe ser agrupada para reflejar el uso de procesos 
cuyos resultados son efectuados por limitaciones de recursos y diferencias 
en la accesibilidad de la información. 


— Un lenguaje de representación de conocimientos debe suministrar 
un conjunto flexible de herramientas, en vez de incorporar compromisos 
específicos sobre estrategias de proceso o la representación de áreas espe- 
cíficas de conocimientos. 


Cada entidad en KRL es representada por una UNIT. Algunas UNITS re- 
presentan conceptos abstractos; otras representan ejemplos específicos de 
esos conceptos. Una UNIT puede definir un objeto desde diferentes pun- 
tos de vista. Er, la figura 4 aparecen ejemplos de UNITs en KRL. Las UNITS 
del Viaje y la Visita representan conceptos abstractos, mientras que la 
UNIT de Suceso137 representa un ejemplo particular de un concepto. En 
realidad, es un ejemplo de dos conceptos, Viaje y Visita. 


LOOPS 


El entorno LOOPS, desarrollado por Xerox, es un sistema de progra- 
mación que incluye varios paradigmas de representación del conocimien- 
to. LOOPS es una extensión de INTERLISP-D (la versión Xerox de INTER- 
LISP). Aunque su nombre parece sugerir otra cosa (LOOPS = Logic Ob- 
ject Oriented Programming System = Sistema de Programación Orientado 
al Objeto), combina los siguientes estilos de programación: orientada a los 
procedimientos, orientada al objeto, orientada al dato y orientada a reglas. 
En el momento actual es aún (como confiesa la propia Rank Xerox) un pro- 
totipo de investigación, aunque lleva tres años siendo experimentado. 


Sus características son las siguientes (respecto de los cuatro tipos de 
programación indicados): 


Programación orientada hacia el procedimiento 


En este paradigma se construyen grandes procedimientos basándose 
en Otros más pequeños, mediante el uso de subrutinas. Los programas y 
datos se mantienen separados. La mayoría de los lenguajes de informática 
son de este estilo. La parte de LOOPS que está orientada hacia procedi- 
mientos es INTERLISP-D (Teitelman, 1978; Xerox, 1982). INTERLISP-D 
aparece en la base del logotipo de LOOPS para sugerir que proporciona 
la base sólida sobre la cual se construye LOOPS (ver fig. 5). 
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OBJET's 
KB's 


Fig. 5. LOOPS según Stefik y Conway*. 


Programación orientada hacia el objeto 


En este paradigma la información está organizada en «objetos», en los 
cuales se combinan instrucciones y datos. Los grandes objetos se constru- 
yen basándose en otros más pequeños. Los objetos se comunican entre sí 
mandándose «mensajes». Las normas para comunicarse con un objeto me- 
diante el uso de mensajes constituye los protocolos de mensajes. Los pro- 
tocolos estandarizados permiten a diferentes clases de objetos responder 
a la misma clase de mensajes. La «herencia» en una clase (dentro de una 
estructura en rea) permite la especialización de objetos. 


Programación orientada al acceso 


Este paradigma es muy práctico para programas que controlan otros 
programas. Su mecanismo básico es una estructura llamada «valor acti- 
vo», la cual tiene procedimientos que son llamados cuando se accede a 
ciertas variables. Una buena forma de imaginarse los valores activos es 
como sondas que pueden ser colocadas en las variables de objeto de un 
programa LOOPS. Estas sondas pueden activar procesos o cálculos adicio- 
nales cuando los datos son cambiados o leídos. Por ejemplo, pueden ma- 
nejar indicadores que muestran los valores de las variables gráficamente. 


Programación orientada hacia reglas 


Este paradigma está especializado en la representación de los conoci- 
mientos para la toma de decisiones en un programa. En LOOPS, las reglas 


* Del Centro de Investigación de Xerox de Palo Alto, California (EE.UU.). 
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son organizadas en «conjuntos de reglas» (rules sets) que especifican las re- 
glas, una estructura de control y otras descripciones de las reglas. 


LOGO 


El LOGO es un lenguaje surgido de los trabajos que Samuel Papert des- 
atrolló en el MIT (Massachusetts Institute of Technology) con la finalidad 
de disponer de un lenguaje sencillo de aprender por los niños, pero que 
fuera poderoso en cuanto a sus capacidades para manejar información. 

Se puede considerar un dialecto de LISP que, como éste, ha sido con- 
cebido para el manejo cómodo de listas. La programación en LOGO per- 
mite al usuario olvidar los detalles de la estructura del programa o de los 
datos y centrar su interés en la representación del conocimiento y su pro- 
ceso. La sintaxis del LOGO es muy sencilla. 

Las diferencias entre LOGO y LISP son básicamente dos: la mayor ca- 
pacidad gráfica de LOGO y la simplicidad del lenguaje. En efecto, en LOGO 
se puede manejar un cursor (suele ser un triángulo o una flecha y se le lla- 
ma «tortuga», cuando se presenta a los niños) que, mediante unos senci- 
llos comandos, se hace mover por la pantalla. Los comandos son claros y 
directos y, como en LOGO se pueden redefinir fácilmente, es usual ma- 
nejarlos en castellano: así se dice AV por «avanza», GD por «gira derecha», 
GI por «gira izquierda», etc. Junto con esta simplicidad de los comandos 
se dispone de la sintaxis cómoda de LOGO: la mayor ventaja es la elimina- 
ción de los paréntesis, tan engorrosos en LISP. Por todas estas razones, se 
puede aprender LOGO muy fácilmente, de un modo interactivo y sin ayu- 
da de ningún profesor: esta es la razón de que se utilice tanto en la alfa- 
betización informática de los niños. 

Desde el punto de vista informático son características de LOGO la fa- 
cilidad de definición y manejo de funciones y la comodidad de recursión: 
en efecto, cuando una función o rutina se llama a sí misma, los paráme- 
tros que el sistema guarda para devolver (al salir de la rutina o función lla- 
mada) se manejan de un modo mucho más ágil de lo que es usual en los 
otros lenguajes de programación (a veces se desechan ciertos valores, in- 
cluso), con lo que el proceso es simple y puede llegar a una recursión infi- 
nita. 

Por ejemplo, para mover los discos en un proceso de paso de una pila 
(INICIAL) a otra (FINAL) en la resolución del problema de las «torres de 
Hanoi» se puede definir el siguiente programa LOGO: 


NDTA 
MEDIA INICIAL CTINA! 


donde hemos utilizado los comandos castellanos PARA, SI y DETENTE (en 
vez de los correspondientes términos ingleses TO, IF y STOP) para definir 
la función TORRES (comando PARA = TO), para establecer el condicional 
(comando SI = IF) y para detener el programa cuando haya concluido el 
proceso de movimiento de los discos de una base a la otra. Como habrá 
observado el lector que conozca el lenguaje LOGO, se ha utilizado en el 
programa el siguiente proceso: se ha descompuesto la tarea de pasar el nú- 
mero correspondiente (¡NUMERO) de discos de la torre INICIAL a la FI- 
NAL (usando la varilla MEDIA) en los siguientes tres pasos: desplazamien- 
to de NUMERO - 1 discos desde la torre INICIAL a la MEDIA, paso del úl- 
timo disco desde la torre INICIAL a la FINAL y superposición de los NU- 
MERO - 1 discos que estaban en la torre MEDIA sobre el que está en la 
torre FINAL. Naturalmente, para los desplazamientos de los NUMERO - 1 
discos que se han indicado, hay que volver a llamar al propio procedimien- 
to TORRES. El comando MOVER.DISCO que aparece en la definición de 
TORRES debe ser definido aparte y deberá realizar la tarea de eliminar un 
disco de la torre que se le da como primer parámetro («INICIAL en el caso 
que hemos descrito) y ponerlo en la torre FINAL. 


Como se ve, el lenguaje LOGO es fácil de comprender y programar, los 
comandos son sencillos y directos, la definición de las funciones se realiza 
de un modo muy simple y no hay dificultad ninguna para definir un pro- 
ceso recurrente. 


KEE 


El sistema KEE (Knowledge Engineering Environment, Entorno de In- 
geniería del Conocimiento) es un entorno de programación desarrollado 
por Intelli Corp., una de las compañías más avanzadas en el desarrollo de 
software y «herramientas» en el área de I.A., en el mundo. Además, ha sido 
incorporado por Sperry como software básico en sus estaciones de trabajo 
para I.A. (sistemas Explorer), pur Xerox en sus sistemas de la serie 1100 
(diseñados especificamente para trabajar en aplicaciones del área de la 
LA.), y por otras compañías. 


Tiene características muy interesantes para preparación de pequeños 
sistemas expertos y prototipos, útiles en Ingeniería del Conocimiento, pero 
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también dispone de lenguajes de programación y herramientas útiles para 
el ingeniero experto. 

Incorpora un sistema gráfico muy flexible que proporciona facilidades 
para la introducción de datos y para su actualización, así como para la pre- 
sentación posterior (gráfica también) de la base de datos preparada, de los 
esquemas y reglas de producción introducidos, etc. Con la primera de es- 
tas facilidades enumeradas, se pueden construir cómodamente prototipos 
de sistemas complejos, con ayudas para ir visualizando los pasos ya dados 
y las informaciones aportadas. Pero, por otro lado, la presentación gráfica 
de los datos hace que sea muy claro el manejo posterior de los pequeños 
modelos ya creados. El sistema dispone de ayudas para la interpretación 
de la información, la partición de los problemas a resolver, el análisis de 
los posibles efectos laterales que se puedan producir y las consecuencias 
de las decisiones que se piense tomar, para la exploración de decisiones 
alternativas, etc. 

Sus características, sin embargo, permiten que los ingenieros expertos 
puedan desarrollar sistemas más complejos con este software; en efecto, 
KEE proporciona varias metodologías muy experimentadas en I.A. que in- 
cluyen la programación orientada al objeto, la representación del conoci- 
miento basada en marcos, la herencia taxonómica, el razonamiento basa- 
do en reglas, el razonamiento dirigido a los datos, un entorno LISP para 
la programación general, etc. 


OPS5 


OPSS5 es un lenguaje concebido específicamente para construir siste- 
mas (especialmente sistemas expertos) basados en reglas (sistemas de pro- 
ducción). El nombre de OPSS significa «Official Production System. Ver- 
sión 5», y el epíteto de «Official» tiene una clara connotación irónica. El 
modelo de «sistema de producción» (para el que está diseñado el OPS5) 
está especialmente indicado cuando el conocimiento que se va a represen- 
tar aparece de un modo natural en forma de reglas (de producción), cuan- 
do el control del programa es extremadamente complejo o cuando se es- 
pera que el programa vaya a ser modificado (de una manera importante a 
lo largo de su período de vigencia (ciclo de vida)). La diferencia básica en- 
tre los sistemas de reglas de producción y los modelos procedurales (clá- 
sicos de los lenguajes de programación convencionales) es la estructura 
de la información que se le ofrece en lo que se suele llamar programa: en 
los modelos procedurales un programa es una secuencia de unidades bá- 
sicas (llamadas «instrucciones») que se ejecutan en un orden establecido 
(aunque se establezcan saltos o bifurcaciones), mientras que en el modelo 
de «sistema de reglas de producción» el «programa» consiste en una co- 
lección desordenada (exactamente, sin orden) de unidades básicas llama- 
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das «producciones», «reglas de producción» o, simplemente, «reglas». Por 
ejemplo, un conjunto de reglas podría tener el siguiente aspecto (escritas 
en castellano pero al estilo OPS5): 


A A AAA A AA 
MEN (entonces) poner categoria 
A 


Siguiendo a Brownston y Farrell (ver referencia bibliográfica) podemos 
decir que las ventajas e inconvenientes que aparecen con la programación 
de OPS5 son las siguientes: 


Expresividad Las reglas expresan fácilmente las actuaciones 
básicas de un proceso de símbolos. 


Sencillez de control. Una consecuencia del formato limitado es que 
todos los datos son guardados en una forma si- 
milar y sólo se necesita una simple deducción 
mecánica. Con el sistema de producción de for- 
mato limitado, como, por ejemplo, los que usan 
encadenamiento hacia atrás, el control no tiene 
que ser especificado explícitamente, evitando 
así proceso oculto. 


N 
bh 


Capacidad 
de reacción 


Modularidad 


Modificabilidad 


Facilidad de producir 
especificaciones 


Lectura de máquina 


Aprendizaje 


Una consecuencia de la separación de conoci- 
mientos y control es que el sistema de produc- 
ción puede enfrentarse con situaciones no pre- 
vistas. Se pueden conseguir influencias recípro- 
cas no previstas (pero útiles) como resultado de 
la utilización de la base de conocimientos cuan- 
do se necesita, en vez de hacer uso de estos co- 
nocimientos de acuerdo con secuencias prede- 
terminadas. 


Una consecuencia de la limitada interacción en- 
tre reglas y de la simplicidad del control es que 
las reglas tienden a ser modulares. Esto facilita 
la capacidad de reacción del sistema; por otro 
lado, esta capacidad facilita tanto la explicación 
como la modificación de reglas. 


Como los conocimientos son almacenados en 
unidades casi independientes, se pueden añadir 
reglas sin causar muchos efectos secundarios. 
Esto facilita el crecimiento del sistema (y tam- 
bién de alguna manera su degradación estética, 
cuando no se encuentran muchas reglas especí- 
ficamente relevantes). 


Otra consecuencia de la separación entre el co- 
nocimiento y el control y del formato restringi- 
do es que las reglas son relativamente fáciles de 
explicar, ya que cada una se refiere a un conjun- 
to muy concreto de conocimientos. La facilidad 
de explicación también depende de la naturale- 
za de las acciones a explicar. 


Los formatos restringidos producen reglas que 
pueden ser leídas por la máquina. Esto hace po- 
sible el limitar la cantidad de modificaciones y 
explicaciones automatizadas, el control de con- 
sistencia y el aprendizaje. 


Mediante un formato estándar las reglas pueden 
ser tratadas como datos y los programas pueden 
entender y manipular sus propias representacio- 
nes, haciendo posible tanto el aprendizaje como 
el conocimiento propio. Sin embargo, se produ- 
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cen influencias nocivas entre la estandarización 
de formatos y la flexibilidad con la cual pueden 
ser representados. 


Paralelismo Pueden a menudo ejecutarse independiente- 
mente unos módulos del sistema de otros, ha- 
ciendo posible de esta manera la eficiencia de 
las computaciones paralelas. 


Se debe tener en cuenta que hay pocos modelos de sistemas de pro- 
ducción que soporten en el proceso en tiempo de ejecución (runtime) las 
capacidades necesarias para el fácil acceso a todas las ventajas citadas. 

Se pueden, por otro lado, indicar algunas desventajas que hay que te- 
ner en cuenta al utilizar un sistema de producción como modelo de pro- 
ceso de conocimiento: 


Dificultades de Si un sistema tiene un formato muy restrictivo 
expresión los conocimientos no pueden siempre ser repre- 
sentados de una manera tan estructurada como 
un modelo de sistema de producción exige. 
También, las limitaciones en los operadores 
booleanos (lógicos) permitidos en las condicio- 
nes de las reglas pueden forzar a la creación de 
reglas múltiples que incluyen condiciones simi- 


lares. 
Control poco Una consecuencia de la comunicación limitada 
clarificado entre reglas, la separación de control y conoci- 


mientos, y el tener una simple deducción mecá- 
nica, es que algunos diseños de control como se- 
cuencias y bucles complejos, son difíciles de es- 
pecificar. Es más difícil expresar y conectar con- 
ceptos en grandes estructuras que en reglas sim- 
ples, incluso cuando estos conceptos son esen- 
cialmente fáciles. 


Comunicación no A pesar de la independencia de las reglas (opcio- 

deseada entre reglas nal), pueden surgir problemas por la aparición 
de comunicaciones inesperadas entre reglas. Es- 
tas intercomunicaciones son una consecuencia 
de la limitación de la comunicación y de la se- 
paración del control y los conocimientos. 
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Comportamiento Las intercomunicaciones limitadas y la natura- 

no transparente leza básica de las acciones de las reglas, además 
de la dificultad de localizar el control, hacen ma- 
terialmente imposible el entender y predecir el 
comportamiento de los sistemas de producción 
que usan estrategias de resolución de conflictos 
o que introducen un complejo control dentro de 
las reglas. Esto también dificulta las explicacio- 
nes y modificaciones. 


Dificultad En parte, como resultado del comportamiento 

de desarrollo no transparente del sistema, y en parte porque 
están muy poco desarrollados los entornos de 
programación de algunos sistemas de produc- 
ción, las facilidades para el desarrollo (debug- 
ging) en los lenguajes de sistemas de producción 
son mínimas. 


Lentitud La mayoría de los sistemas de producción se eje- 
cutan a una velocidad uno a dos órdenes de mag- 
nitud más lenta que los programas orientados al 
procedimiento, porque el evaluador (matcher) 
tiene que reconsiderar toda la situación para en- 
contrar reglas aplicables a cada ciclo. 


APLICACIONES DESARROLLADAS 
EN LENGUAJES CLASICOS 


Como contraste con las aplicaciones descritas y los lenguajes específi- 
cos utilizados para la resolución de problemas de 1.A., se comentan a con- 
tinuación dos ejemplos de sistemas desarrollados con técnicas, conceptos 
y mentalidad de 1.A. pero en lenguajes convencionales (procedurales), con 
una eficacia grande, como ya se ha comentado. 


EX-TRAN 7 


Es un paquete diseñado para construir sistemas expertos desarrollado 
en lenguaje Fortran. EX-TRAN 7 significa EXPERT TRANSLATOR a For- 
tran 77. En efecto, se han codificado en este lenguaje el motor de inferen- 
cia de un sistema experto y el generador inductivo. El experto puede faci- 
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litar las reglas al sistema bien de un modo explícito o bien de un modo in- 
directo por medio de archivos o ejemplos. Las reglas se generan en For- 
tran 77 y pueden, por tanto, ser linkadas con rutinas adicionales externas 
en Fortran. La estructuración flexible de las reglas permite establecer en- 
tre dichas reglas una dependencia jerárquica en el sistema experto resul- 
tante. La eficacia del sistema es enorme y, de hecho, ya se han construido 
varios sistemas expertos (y se están explotando) utilizando EX-TRAN 7. Ha 
sido desarrollado por la compañía británica Intelligent Terminals Ltd. 

Las características básicas de EX-TRAN 7 son las siguientes, según sus 
autores: 


— Las soluciones generales (en base a reglas) por el problema a resol- 
ver, son simples y claras. 

— La estructuración flexible de las reglas permite establecer una de- 
pendencia jerárquica muy útil. La estructura de las reglas es controlada 
por el usuario desde el archivo base de texto. Se puede modificar comple- 
tamente la estructura del sistema experto cambiando el texto del archivo 
base, aunque se mantenga el mismo conjunto de reglas. 

— Se pueden incluir en el conjunto subrutinas externas (en Fortran) 
para poder preparar más fácilmente la captura de datos, soportar el com- 
ponente de control de atributos (parte «if» de las reglas «if-then»), super- 
visar la validez de la porción «then» de las reglas, etc. Incluso estas rutinas 
externas facilitadas (e «incluidas dentro de») al sistema experto puede rea- 
lizar cálculos intermedios necesarios en la ejecución de las reglas. 

— Las reglas necesarias para la solución del problema se le pueden 
proporcionar directamente a EX-TRAN 7 o bien puede el sistema inferir- 
las inductivamente a partir de un conjunto de decisiones ejemplo que se 
le facilite; para esta tarea está dotado el sistema de un módulo específico 
de «aprendizaje inductivo». Esta cualidad es esencial en algunos proble- 
mas para los que no existen (o los expertos no son capaces de formular ex- 
plícitamente) reglas suficientes sobre «cómo hacerlo». 

— EX-TRAN 7 genera automáticamente a partir de las reglas, código 
fuente en Fortran 77, de tal modo que (una vez compilado) puede ser uti- 
lizado en la versión final («runtime») del sistema experto. 

— Existen comandos de usuario para dirigir la operación general del 
sistema (en todas sus fases) de un modo cómodo. 

— En el sistema experto resultante se incorpora un conjunto de ele- 
mentos de ayuda (bajo petición) a utilizar en el momento de su uso. Con 
ello se puede hacer más cómoda y clara la utilización del sistema experto 
y se pueden incluir, además, capacidades de autoaprendizaje para los me- 
nos expertos. 
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MXA 


Este sistema está concebido como un shell o sistema concha; es decir, 
es un sistema de interface de usuario. Fue creado como una herramienta 
para la investigación acerca de cómo aplicar las técnicas de los sistemas 
expertos a la fusión de datos de sensores para obtener una interpretación 
continua de las informaciones obtenidas de un conjunto diverso de senso- 
res de tipo militar. MXA incorpora el modelo básico de funcionamiento 
de un grupo de «fuentes de conocimiento» que interactúan con una base 
de datos ubicada en la memoria principal del equipo que soporta a este sis- 
tema. Para esta aplicación de MXA cada fuente de conocimiento consiste 
en un grupo de reglas de condición-acción con el conocimiento procedu- 
ral soportado por la habilidad de usar funciones y procedimientos en las 
reglas. 

El lenguaje de representación del conocimiento es una extensión de 
Pascal y la gran ventaja de MXA es, precisamente, que el compilador 
correspondiente genera lenguaje fuente Pascal para que sea compilado 
también. 

Los principales objetos que maneja el sistema son hipótesis. Cada una 
de ellas es una ocurrencia de un tipo específico de datos y tiene la forma 
de un registro Pascal. 
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INTRODUCCION 


AL como hemos comentado, LISP es el lenguaje por ex- 
celencia de la Inteligencia Artificial. Para el desarrollo de 
aplicaciones en este área de la informática se utilizan tam- 
bién otros lenguajes, pero de aplicación más restringida: 
PROLOG (al que dedicamos el próximo capítulo) aunque 
está concebido específicamente para desarrollar «progra- 
mación lógica», ha adquirido un extraordinario auge por 
su capacidad de deducción, sobre todo en la programa- 
=== ción de sistemas expertos y en el procesamiento del len- 
guaje natural (áreas de enorme popularidad, hoy en día); SMALLTALK se 
utiliza para la programación «orientada al objeto», cuando esta forma de 
representación del conocimiento es la más adecuada al problema que se 
va a abordar; LOOPS es un entorno de programación que incorpora LISP 
y PROLOG y otras muchas herramientas para una programación eficaz; e 
incluso, se han desarrollado sistemas específicos para la resolución de pro- 
blemas concretos (programación de «sistemas expertos», específicamen- 
te). Sin embargo, LISP sigue siendo el lenguaje más universalmente exten- 
dido (más aún en EE.UU. que en Europa o Japón) para los desarrollos de 
Inteligencia Artificial en general. 


LISP es un lenguaje simbólico (pues está pensado para procesar pala- 
bras y frases, listas), en contraposición a los lenguajes numéricos (aunque 
también maneja números, claro está). 


Por otro lado, LISP es un lenguaje típicamente funcional: las activida- 
des básicas son realizadas por funciones (porción de código que devuelve 
un objeto a partir de otro u otros objetos), bien sean funciones primitivas 
(definidas en el propio intérprete), bien funciones definidas por el usuario. 
Programar en LISP es, en gran medida, definir funciones adicionales y 
combinarlas con las ya existentes. Una de las características del lenguaje 
que suele agradar más al programador en LISP es, precisamente, la faci- 
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lidad y flexibilidad que proporciona el lenguaje para que el usuario defina 
funciones adicionales. 

Desde luego, no es LIPS el único lenguaje simbólico en que se pueden 
definir fácilmente funciones adicionales: en LOGO, por ejemplo, se pue- 
den realizar estas actividades también. Pero LISP dispone de primitivas 
muy potentes en el manejo de listas y estructuras de control de proceso 
bastante útiles. (Aunque LOGO, quizá, sea más cómodo, más simple y con 
mejores capacidades gráficas (?)). 

En este capítulo vamos a presentar un LISP un poco genérico (pareci- 
do quizá a MacLISP y, en algunas cosas, a CommonLISP), pero que espe- 
ramos sea suficiente para una buena introducción a la programación en 
este interesante lenguaje. La versión de LISP de que disponga el lector no 
coincidirá totalmente con todos los detalles de la sintaxis que vamos a uti- 
lizar, pero podrá fácilmente detectar las pequeñas diferencias existentes (y 
a las que iremos aludiendo) consultando el manual que le haya facilitado 
el suministrador del intérprete que vaya a manejar. 

Sería muy útil disponer de un intérprete de LISP para ir practicando 
los ejemplos que se dan en el texto, pero no es imprescindible para enten- 
der el contenido de esta presentación y tener una buena idea de cómo se 
puede programar en LISP y cuáles son las características básicas (y dife- 
renciales) de este lenguaje. 


LL 


CONCEPTOS DE PROGRAMACION 


Las informaciones que se manejan en lenguaje LISP, los datos, pueden 
ser elementos simples o listas; a los elementos simples se les llama tam- 
bién átomos. En ocasiones, cualquier dato que se procese en LISP (áto- 
mos y listas) es llamado «objeto», especialmente cuando se manejan con- 
ceptos de «programación orientada al objeto». 

Un átomo es un conjunto de caracteres (caracteres alfabéticos, numé- 
ricos o signos especiales) sin separación alguna (sin incluir espacios). 

En LISP son distintos, a todos los efectos, las mayúsculas de las minús- 
culas; y, por tanto, son distintos los identificadores NUEVOVALOR, nue- 
vovalor, nuevo-valor, Nuevo-valor, NuevoValor, etc. 

Los átomos pueden ser números o símbolos (también llamados identi- 
ficadores). Algunas versiones sencillas de LISP sólo utilizan números en- 
teros (con o sin signo). 

Por el contrario, en los identificadores o símbolos se admite la presen- 
cia de caracteres numéricos o signos especiales. (A veces se exige que el 
primer carácter de un identificador sea alfabético). Los identificadores 
pueden ser constantes o variables (los números son constantes). Los iden- 
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" tificadores constantes pueden ser, a su vez, constantes literales, nombres 
de función o predicados y símbolos especiales (como «T», que representa 
el valor true = verdad). 


Números (constantes) 


Constantes literales 


Nombres Predicados 
Atomos Constantes al a 
funciones 
Símbolos o Símbolos especiales 
Elementos del identificadores 
lenguaje 
Variables 


Listas 


Fig. 1. Elementos del lenguaje LISP. 


Una lista es un conjunto de elementos de lenguaje (átomos o listas) se- 
parados por espacios e incluidos en unos paréntesis. Una lista puede con- 
tener, a su vez, como elementos a otras listas. Existe la lista vacía, sin ele- 
mentos (se escribe «()»). 

Al conjunto de átomos y listas se le denomina S-expresión (o expre- 
sión-S, castellanizando el término) y significa «expresión simbólica»: el tra- 
tamiento de estas S-expresiones es el objeto del lenguaje LISP. 


Manejo de listas 


Tal como hemos comentado, el elemento básico de datos en LISP es 
la lista. Una lista (sucesión de elementos separados por espacios y encua- 
drados entre paréntesis) puede contener, a su vez, listas; pero cada lista 
que incluye debe ser considerada como un único elemento. Así, la lista: 


(X Y))»), cuyo cuarto elemento es una lista de dos átomos; el cuarto ele- 
mento de la lista primera es la lista vacía (no tiene ningún elemento). 
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A veces, la lista vacía se representa por la constante «NIL», pues en la 
sintaxis del lenguaje son equivalentes. 


Es importante, cuando se van a procesar listas, distinguir el primer ele- 
mento de la lista de los restantes elementos: el primer elemento se llama 
«cabeza» de la lista y el resto de elementos (ninguno, uno o varios) es la 
«cola» de la lista. Así, en la lista anterior la cabeza es «ARTI», mientras la 
cola es (X1 (A BC (X Y)) ((M). 

Existen dos funciones primitivas de LISP para realizar la separación de 
estos dos elementos de una lista: son las primitivas «CAR» y «CDR». (Una 
función se llama «primitiva» si está definida de origen con el intérprete o 
compilador del lenguaje: las tareas básicas a realizar en LISP disponen de 
sus correspondientes funciones primitivas, aunque el usuario puede fácil- 
mente —ya lo veremos— definir sus propias funciones. ¡Esa es una de las 
características que más agradan al programador de LISP!) 

La función CAR devuelve el elemento (átomo o lista) que forma la ca- 
beza de la lista. Así, 


devolverá el átomo «ARTI»; mientras que CDR (se lee «coulder», en in- 
glés) devuelve una lista formada por los restantes elementos de la lista ori- 
ginal: 


(Obsérvese que hemos puesto un apóstrofo «'» delante de la lista que da- 
mos a «CAR» o «CDR»; este apóstrofo es imprescindible (tecléelo sin após- 
trofo y comprobará que el intérprete le da un mensaje de error), pero su 
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significado se verá más adelante. Por ahora tómelo simplemente como un 
modo peculiar de escribir los argumentos de las funciones primitivas 
«CAR» y «CDR». Por otro lado, habrá observado que el conjunto total for- 
mado por la función —CAR o CDR— y su argumento, lo escribimos siem- 
pre entre paréntesis: en LISP ha de ser así). 

Es útil decir expresamente que (como era de esperar, por otro lado): 


ad 
e 


devolverá el valor «UNICO», mientras que 


devolverá el valor «NIL>» (representando a la lista vacía; en latín «nada» se 
dice «Nihil» o «Nil»). 
Por otro lado, si introducimos: 


el intérprete dará un mensaje de error, pues ambas funciones necesitan 
un argumento en forma de lista (no un átomo). 

También suele suceder que (CAR NIL) o (CDR NIL) den como resulta- 
do «NIL», pero hay versiones de LISP que dan error en esos casos. Subra- 
yamos que las anteriores expresiones son equivalentes a (CAR ()) y (CDR 
()), respectivamente. Además, obsérvese cómo NIL es a la vez un átomo 
(un símbolo o identificador especial) y una lista (no da error (CAR NIL), 
normalmente). 

Por último, hay que decir que se pueden hacer llamadas consecutivas 
o «anidadas» a estas funciones. El intérprete admite la expresión: 
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y da como resultado la lista (B C) (asegúrese de que sabe por qué); si, por 
el contrario, introducimos: 


sucederá ahora que la primera evaluación (de «CAR») dará por resultado 
«(A (B C))» y el «CDR>» posterior selecciona la cola (es decir, «(B C)») y la 
da como una lista ((B C)). (La diferencia es el doble paréntesis que aparece 
como resultado de «CDR»). 

El anidamiento se puede llevar tan lejos como queramos y podemos, 
por tanto, escribir: 


para obtener el cuarto elemento de la lista, es decir «D». 

Normalmente, el intérprete de LISP dispone de funciones especiales 
que sustituyen con seguridad y comodidad a los anidamientos de CAR y 
CDR; suele existir la función «CADR», definida como «el CAR del CDR de 
la lista»: 


(es decir, B) 


y la función «CDAR>» que será: 


0 


6 


Hay que observar que la expresión anterior dará error, pues el CAR de la 
lista es el átomo «A», y se da a CDR un átomo —no una lista— lo que pro- 
duce error. Por el contrario: 


opuesta a la «separación» de elementos de la lista: es «CONS», que permi- 
te «CONStruir» una nueva lista añadiendo un elemento delante de una lis- 
ta dada. Los argumentos de la función primitiva «CONS» son un átomo y 


dará como resultado (A B C), mientras que: 


3 


SN] 


y dará (A) o bien: 


A A A o 
is Anora (va bien)) 
A 


pues devolverá ((Esto está) mucho peor). 


Para comprender claramente por qué CDR devuelve la cola de la lista 
como una lista (aunque esté formada por un solo elemento), mientras que 
CAR devuelve la cabeza como un átomo, por qué CONS une un átomo (y 
no una lista) con una lista... y, en general, cómo se pueden procesar en 
LISP las listas, es útil ver de qué modo LISP considera y maneja las listas. 
La representación interna de las listas se hace en lo que se llama «cadena 
de celdas CONS», que son unos «casilleros» o «celdillas» donde se alma- 
cenan los diferentes elementos de la lista y los «punteros» o «indicadores» 
que señalan al siguiente elemento de la lista. 


Sin embargo, es más clara (aunque no sea tan precisa) una represen- 
tación en forma de «árbol binario», y será suficiente para nuestros pro- 
pósitos. Un «árbol» es una representación de unalestructura general de da- 
tos O de una secuencia de procesos o elementos, de tal modo que en cada 
nudo del árbol aparece uno de los elementos de unión y en cada rama las 
dos partes en que ese elemento de unión divide la secuencia dada. Por 
ejemplo, en la figura 2 aparece un árbol que puede representar la frase «Si 
tomamos un taxi y el taxi no pincha, llegaremos a tiempo». El árbol es «bi- 
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Fig. 2. Un árbol binario. 


nario» porque de cada nodo «no terminal» parten a lo sumo dos ramas. 
Un caso muy concreto de árbol binario es el que se puede utilizar para re- 
presentar una lista. 


E 


Fig. 3. Arbol representativo de una lista plana. 
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En la figura 3 aparece el árbol representativo de la lista (A B C D E), 
mientras que en la figura 4 aparece un árbol más complejo para la lista 
(más complicada) (A (B C) D (E F) G). 

Sobre estos árboles establecemos la norma siguiente: «las ramas que es- 
tán hacia la derecha son subárboles —y representan listas, por tanto— las 


ramas que están hacia la izquierda se consideran átomos en la composi- 
ción o análisis 


(1) 


F 
Fig. 4. Arbol binario representativo de una lista jerárquica. 


—aunque sean, a su vez, listas—». La función CAR separa la rama de la iz- 
quierda en cualquier nudo y la función CDR separa la rama (o árbol) de 
la derecha. Así en el nodo 1 se tiene que: 


GS) > 


devuelve A, mientras que: 


Po -:L:híéó5é<=HH- AAA 
Po -u-iLLiíLíK:5E5S== >> dy. 
e Lauauau=zaH=SXEES=S=<=AA AF 


(CDRAAIBCIDIE FG) 
(DK AID O)DA y) 


devuelve: 


En el nodo 2 los valores son: 


que devuelve (B C), mientras que: 


devuelve: 


Y en el nodo marcado con 3, serán: 


Mediante estos árboles se ve más fácilmente cómo se podría escri- 
bir de otro modo estas listas: en efecto, si consideramos el punto que apa- 
rece en cada nodo del árbol de la figura 4 como un conector binario (es 
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decir, que une dos operandos), el árbol que nace en el nodo 4 se podría 
escribir: 


(recuérdese que la rama de la derecha debe ser considerada árbol —lis- 
ta— y debe ser puesta, por tanto, entre paréntesis y la de la izquierda no). 
Del mismo modo, el árbol que nace a partir del nodo 3 será: 


y por fin, el conjunto del árbol (representativo de la lista que considerá- 
bamos al principio): 


ESAS == ASS == IAS == AE DESS ASS 


- En efecto, LISP admite esta otra representación; es más, si tecleamos 
en el ordenador la expresión «punteada» anterior (con un apóstrofo, como 
siempre), LISP devolverá como valor de esa secuencia el siguiente: 


(Es muy común que el intérprete de LISP necesite que se ponga un es- 
pacio delante del punto y otro detrás, para separarlo del resto de los ele- 
mentos. Preste atención a este detalle si su intérprete es de este tipo.) 


Es decir, es equivalente (E. (F)) y (E F); y la forma de representarlo grá- 
ficamente es mediante un árbol equivalente. Si utilizamos la función pri- 
mitiva CONS para «construir» este árbol o lista debemos escribir: 


b 


z 


Sin embargo, se puede utilizar CONS de otro modo para dar lugar a la 
estructura que se llama «par punteado». Si escribimos el segundo paráme- 
tro de CONS no como una lista sino como un átomo, la función no dará 
error, sino que construirá un par punteado. En efecto, introduzca usted la 
expresión: 


y verá que el valor que LISP asigna a esa secuencia es: 


(que es diferente de (A B)). 

(Esto equivaldría en el árbol a suprimir la condición impuesta de que 
la rama de la derecha debe ser considerada una lista —otro subárbol—.) 

Esta nueva estructura de datos es muy útil en algunas ocasiones, en ca- 
sos especiales. Aunque no entremos aquí en la utilización del par puntea- 
do frente a la lista y en las diferencias de utilización de CONS y LIST (pri- 
mitiva que veremos a continuación), diremos que es muy útil en el análi- 
sis léxico-gráfico y procesamiento del lenguaje natural. 

Otra cuarta primitiva utilizada en el manejo de listas es LIST. Con ella 
se construye una lista con los argumentos que se le dan, tal cual (es decir, 
si aparecen como listas, los incluye como listas; si aparecen como átomos, 
como átomos). La función LIST admite cualquier número de argumentos 
(no necesariamente dos, como CONS). De este modo, podemos hacer: 


y obtendremos como resultado: 


ES 
W 


Si escribimos: 


obtendremos: 


Manejo de números 


Aunque LISP ha sido concebido especialmente para el manejo de lis- 
tas, también dispone de herramientas para el proceso de números. Bási- 
camente, vamos a considerar dos grupos de funciones para el proceso de 
números: algunos predicados y otras funciones aritméticas. 

Un predicado en LISP es una función que a partir de sus argumentos 
(normalmente uno o dos) devuelve uno solo de dos posibles valores: ver- 
dadero o falso. Se representa el verdadero por «T» (True, es verdadero en 
inglés); el valor falso está representado por NIL (como la lista vacía). 

En cada versión LISP estarán disponibles unos u otros de los predica- 
dos y funciones usuales: aquí presentaremos los más utilizados, pero si en 
el LISP que usted tiene a mano no están incluidos podrá definirlos des- 
pués fácilmente. 

También se utilizan predicados en el manejo de listas e incluso algu- 
nos predicados (como EQUAL, que se ve a continuación) son válidos para 
símbolos y números. Ahora presentamos algunos predicados que se utili- 
zan con frecuencia en el proceso de números y más adelante se describirá 
el resto. La mayoría de los predicados tienen una «P» al final del nombre 
(ZEROP, NUMBERP, LESSP...), pero no es imprescindible. 
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EQUAL es un predicado muy utilizado (a veces aparece simplemente 
como EQ): significa «igual» y devolverá T (true, cierto) si los dos argumen- 
tos que se le dan son iguales; en caso contrario, devolverá NIL (falso). De 
este modo: 


dará valor T así como: 


e, incluso: 


si previamente hemos asignado a «X>» el valor «A» (ya veremos cómo se 


asignan valores a las variables). Por el contrario, serán NIL las siguientes 
listas: 


DONNA 2A ¿A 
(FEOUAL A (A)) 
K— a 


(EOUAL X (X et 
(ENVIA MA AM) 


En algunos dialectos se dispone de varias versiones de la igualdad se- 
gún se trate de listas o números e, incluso, en alguno existe una pequeña 
diferencia entre EQ y EQUAL (en contra de lo que hemos dicho antes) res- 
pecto a la ubicación en memoria de los objetos o a su representación in- 
terna o a su concepción formal..., pero estos detalles, por ahora, no le de- 
ben preocupar al lector. Hay dialectos de LISP que admiten el signo de 
igualdad (=) en vez de EQUAL cuando se están comparando números. 

Otro predicado interesante es LESSP (menor que), que comprueba si 


4 


ul 


z 


el primer número que se le da es menor (devuelve T) o no (devuelve NIL) 
que el segundo número. Serán T las expresiones: 


si X tiene valor numérico menor que Y. 


También disponemos de GREATERP (mayor que) para comprobar la 
condición contraria. Así serán verdad (T): 


en el mismo supuesto anterior. 


En ocasiones es útil comprobar los valores individuales de alguna va- 
riable. Suele disponerse de varios predicados con esta finalidad: 


ZEROP comprueba si el valor que se le da como argumento 
vale exactamente cero. 
ONEP comprueba si vale «1» precisamente la constante o va- 
riable que se le da. 
ODDP será verdad si el número dado es impar (ODD en in- 
glés); en caso contrario valdrá NIL. 


Vamos a anotar, por último, que existe un predicado especial, «NOT», 
para cambiar de valor al predicado al que se aplica. Es decir, si la expre- 
sión que se pone de argumento de NOT es T, el resultado será NIL; si, por 
el contrario, la expresión a la que se aplica NOT vale NIL, el conjunto ten- 
drá un valor de T. Así, serán T las siguientes expresiones: 


bh 
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pues (NOT 12) es NIL, al ser 12 un número y no un predicado que valga 
NIL (normalmente, NOT dará NIL con cualquier átomo que no valga pre- 
cisamente NIL —o dará error—). 


Pero para el manejo de números disponemos de funciones primitivas 
más sofisticadas que nos permiten realizar numerosas operaciones aritmé- 
ticas: 


PLUS («mas») produce la suma de los valores que.se le dan 
como argumentos: 


será T, pues (PLUS 3 2) da como resultado 5. A veces 
en vez de PLUS se utiliza el signo de la suma (+). Algu- 
nos dialectos admiten la suma de varios números, y no 
exactamente dos. Así, en un dialecto que admite estas 
variantes, tendrá valor T la siguiente expresión: 


(= (+6 -2 5 3) 12) 


DIFFERENCE — devuelve como resultado la diferencia de los dos argu- 
mentos que se le dan: 


TIMES («veces») devuelve el producto de los números. Así «TI- 
MES 3 4» habrá que leerlo como «3 veces 4», es decir, 
3 x 4. En algunas versiones de LISP se aceptan produc- 
tos múltiples; en otras se usa el asterisco (*) como sím- 


47 


bolo del producto, en vez de TIMES (a veces la función 
«MUL»). 


QUOTIENT - da el cociente de la división. Es muy normal que QUO- 
TIENT dé el cociente entero de la división (si el LISP 
de que disponemos sólo maneja enteros, es imprescin- 
dible). En este caso se puede utilizar otra función para 
obtener el resto. 


REMAINDER da, precisamente, el resto de la división entera de los 
dos argumentos que se le ponen. 


En vez de QUOTIENT se utiliza, a veces, «DIV» o bien «/» y la división 
puede ser múltiple, dividiéndose el primer número por el segundo, el co- 
ciente entre el tercero, el resultado entre el cuarto, etc. Respecto del res- 
to, hay dialectos en que se da el resto por defecto siempre, otros en que 
se da el menor (por defecto o por exceso), etc. Para ver estos detalles y 
otros muchos que irán apareciendo (así como la nomenclatura exacta 
(DIV, QUOTIENT, /, etc.) deberá consultar el manual del LISP que esté us- 
ted utilizando en su ordenador. 
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Hay otro conjunto de funciones que suele estar disponible en los dife- 
rentes dialectos de LISP (aunque aquí la variedad es mayor) y que son su- 
mamente útiles. Comentemos algunas de las más usuales: 


ABS da el valor absoluto de un número: 


ADD1 devuelve un número una unidad mayor que el que se 
da como parámetro: 


(a veces, la función ADD1 aparece como «1+») 


SUB1 devuelve el número resultante de restar una unidad al 
argumento: 


(a veces, la función SUB1 se escribe como “1-”) 


MIN da como resultado el número menor de entre una lista 
que se le da: 
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No) 


MAX de un modo parecido a la anterior, devuelve el mayor 
valor: 


Evaluación de expresiones y 
asignación de valores 


Antes de continuar describiendo los elementos del lenguaje, conviene 
detenerse a considerar cómo actúa el propio intérprete de LISP, para acla- 
rar algunos aspectos de la sintaxis del lenguaje. 

En todo lo que hemos descrito, hemos manejado sencillas expresiones 
encabezadas casi siempre por una función. Y la frase usual ha sido «si te- 
cleamos tal expresión, el intérprete devolverá el valor cual», o expresio- 
nes semejantes. De hecho, esas afirmaciones reflejan el modo de actuar 
del intérprete de LISP, normalmente. 

En efecto, el núcleo central del sistema es el evaluador. El evaluador 
de LISP es un «programa» que realiza un bucle básico en tres etapas: lec- 
tura, evaluación, escritura. Para cada frase LISP que se introduzca, se rea- 
liza este ciclo (salvo excepciones en que se rompe el ciclo normal). Por 
ello, este evaluador debe ser sumamente eficaz. 

En la primera etapa (lectura), se toma la frase que se introduce y se exa- 
mina para comprobar que se cumplen ciertas normas básicas de la sin- 
taxis del lenguaje. Si se detecta alguna anomalía se da el mensaje corres- 
pondiente (el más usual es que faltan paréntesis) y se vuelve a la situación 
de lectura, hasta completar una frase LISP bien construida (una S-expre- 
sión). 

La segunda fase, la etapa básica, es la de evaluación: el evaluador cal- 
cula (evalúa) los valores de los argumentos, llama a la función correspon- 
diente y calcula el valor final; o sencillamente, evalúa el átomo que se le 
ha dado en la S-expresión. En ocasiones la función es compleja y los valo- 
res resultantes de la evaluación de una función se pasan a la siguiente o 
siguientes, de tal modo que la evaluación se realiza a varios niveles. A ve- 
ces se producen «efectos de borde» (veremos lo que son) en la evaluación 
de una S-expresión. 

En la tercera etapa se escribe el valor obtenido en la evaluación ante- 
rior. 
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Pero ¿cómo se realiza exactamente esta evaluación? La frase LISP o 
S-expresión puede ser un átomo o una lista, como hemos indicado. 

El átomo puede ser constante o variable. Una constante se evalúa por 
su propio valor; es decir, un número se evalúa por el valor que representa 


z 


(hemos supuesto que «?» es el «prompt» (aviso) del LISP y, por tanto, lo 
que aparece en las líneas que comienzan por «?» son los valores que te- 
cleamos cuando el intérprete nos da el aviso de que está listo. En la línea 
siguiente aparece la «respuesta» de LISP: el resultado de la evaluación que 
ha realizado). 

Se observará que cuando introducimos un identificador de valor no 
predefinido (una variable) que no corresponde tampoco a una función, el 
intérprete manda un mensaje de error (en su ordenador el mensaje de error 
tendrá otro formato y estará, problablemente, escrito en inglés). Si, por el 
contrario, hubiéramos asignado previamente un valor a Variable (la hu- 
biéramos «ligado»), el intérprete la evaluaría al valor que tiene. 

Esta asignación la podemos hacer con la función SETO (ya veremos en 
detalle cómo) y el diálogo con el ordenador podría continuar: 


Ahora no se produce error, sino que «Variable» se evalúa al valor con 
el que se ha ligado (es decir, 12). 
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La segunda posibilidad es que el evaluador reciba una lista. En este 
caso, supone que la cabeza de la lista será una función y el resto (la cola) 
serán sus argumentos. Por tanto, buscará entre las funciones disponibles 
(es decir, las predefinidas en el LISP en el que estemos trabajando, más 
las definidas por el usuario) la que se le solicita y la ejecuta con el valor 
de los argumentos. Si no existe esa función, dará un mensaje de error. 

Pero para ejecutar la función, previamente ha de evaluar los argumen- 
tos. En la evaluación de los argumentos se aplican las mismas reglas des- 
critas: es decir, si un argumento es una constante se evalúa en su propio 
valor; si es una variable, en el valor con el que se ha ligado (el valor que 
se le ha asignado) y si es una lista se supone que el primer átomo es una 
función y los restantes sus argumentos (argumentos que habrá que eva- 
luar, de nuevo, antes de evaluar la función). 


Así, por ejemplo, si introducimos la expresión: 


=%YY%% SS 
==—====—__—_ —_—_——_>5 


el evaluador entiende que esa lista (de tres elementos) es una función y, 
por tanto, comprueba que tiene definida la función PLUS. A continuación 
evalúa sus dos argumentos. El primero es, a su vez, una lista: por tanto, 
comprueba que tiene definida la función TIMES, evalúa -2 (al valor -2; es 
una constante), evalúa 3 y calcula (TIMES -2 3), obteniendo, lógicamente, 
como valor del primer parámetro de PLUS, el número -6. El segundo ar- 
gumento de PLUS se evalúa a cuatro. Por último, el cálculo de (PLUS -6 
4) hace que la expresión global se evalúe en -2, que es el valor que de- 
vuelve el intérprete de LISP. 


Si hacemos, por otro lado: 


__ QOA€457457** O 1 5 A A 
A A 
A A A A q _-__  __—_— 
a 


obtendremos la lista: 


pues la lista introducida incluye en cabeza una función (CONS) y las otras 
dos expresiones (sus argumentos) tienen asignados los valores T y NIL, res- 
pectivamente. . 


Si, por el contrario, hacemos: 


el evaluador dará error, porque al ir a evaluar los argumentos de la fun- 
ción CONS se encuentra con la «variable» «HOLA» que no tiene asignado 
ningún valor. Producirá un error indicando que «HOLA» está no ligada 
(probablemente el mensaje será algo parecido a «Error: unbound variable. 
HOLA»). Como lo que queremos conseguir en este caso es, sencillamente, 
que LISP construya una lista con esas tres palabras, debemos indicarle que 
no evalúe los parámetros, sino que los tome tal como se los damos: insis- 
timos, si no se le indica nada, LISP siempre evalúa las expresiones que se 
le dan. Para indicarle que no evalúe algo, se pone delante un apóstrofo «'» 
(«quote», en inglés). De este modo, si le decimos: 


seguirá dando error, pues aunque no evalúe HOLA, intentará evaluar la 
«variable» QUE de la lista (QUE TAL). Pero si escribimos: 


la respuesta del intérprete, una vez evaluada la función CONS con los pa- 
rámetros dados, será: 


ul 
W 


Si introducimos: 


dará error («función no definida») al ir a evaluar el argumento de la fun- 
ción CAR —(HOLA QUE TAL)— ha encontrado una lista y la cabeza de la 
lista —HOLA— no la tiene definida como función. Para evitar que «eva- 
lúe» el argumento que le hemos dado habrá que ponerle un apóstrofo de- 
lante. En efecto, al introducir: 


Por estas razones, si introducimos: 


el evaluador dará error, ya que el primer argumento de PLUS no es numé- 
rico, puesto que se evalúa (se «no evalúa») a (TIMES -2 3) que es una lis- 
ta, y no un número. Insistimos (TIMES -2 3) se evalúa a «-6», mientras 
que '(TIMES -2 3) se evalúa a «(TIMES -2 3)». 

Usualmente en LISP se dispone de una palabra que realiza la misma ta- 
rea que el apóstrofo: es QUOTE. 
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En efecto: 


QUOTE no es propiamente una función: se limita a devolver el valor 
que se pone como argumento. En el argot de LISP se llama a esta estruc- 
tura «forma especial»: 


es equivalente a: 


Por ejemplo, si suponemos que la variable X tiene asignado un valor 
de «Temperatura», la expresión: 


hará que la variable «Temperatura» tenga un valor de 25. Por tanto, se po- 
dría establecer el diálogo: 


ul 
ul 


temperatura 


(obsérvese cómo la expresión (SET X 25) además de atribuir a Tempera- 
tura el valor 25, se evalúa —ella misma— a 25, que es el valor que devuel- 
ve el intérprete de LISP). Insistimos en que, de acuerdo con las «normas 
de evaluación» definidas anteriormente antes de llamar a la primitiva 
«SET», el evaluador de LISP evalúa ambos argumentos (25 se evalúa a 25 
y X, una variable, al valor al que esté ligada, suponemos que «Temperatu- 
ra»). 


Sin embargo, puede haber casos en que no nos interese evaluar el pri- 
mer argumento (o ambos). Para ello, pondremos el apóstrofo (o QUOTE) 
delante del argumento. 


Por ejemplo, para ligar la variable «X» con el valor «Temperatura» 
(paso previo al anterior que consistía en asignar a «Temperatura» el valor 
25) debemos escribir: 


así LISP no evalúa ni «X» ni «Temperatura», sino que, sencillamente, «liga» 
la variable «X» con el valor «Temperatura». El diálogo completo podía ser: 


o 5 
e 
e 


temperatura 


¿(SEI A 23) 


O también: 


donde se pone «SETO» para asignar a «Variable» el valor «12», sin evaluar 
«Variable», pues como «Variable» no estaba ligada a ningún valor, daría 
error la expresión: 


0 
N 


Existe una función primitiva (EVAL) que produce el efecto contrario a 
QUOTE: en efecto, con «quote» se inhibe la evaluación de un átomo con 
«EVAL» se «fuerza» dicha evaluación. Así, por ejemplo: 


se evalúa a 6, mientras que: 


se «evalúa» a (TIMES 2 3), como hemos dicho. Por el contrario: 


se evalúa, de nuevo, a 6. 


Otra función relacionada, asimismo, con el proceso de evaluación es 
APPLY. Esta primitiva procesa un átomo (que debe ser una función) y ina 
lista (que deben ser los argumentos de dicha función) y «aplica» los argu- 
mentos a la función para su ejecución, sin evaluar previamente ni el áto- 
mo representativo de la función ni la lista de los argumentos. Así: 


se evalúa a 6 y. 


se evalúa a 2. 
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Efectos laterales 


Hemos visto que, como resultado de todas las evaluaciones en LISP, el 
intérprete «devuelve» el valor obtenido en la evaluación pero que, además, 
se pueden producir otras acciones. Estas acciones son, a veces, más im- 
portantes que el propio valor devuelto: son los llamados «efectos latera- 
les» de la evaluación. 

Por ejemplo, si hacemos 


el intérprete eo cantó A y la obtención de este valor es el efecto principal 
esperado; o bien'en 


que devolverá T si X está ligada previamente al valor «A» o «NIL» si no 
es así. 

Pero hay otros casos en que el valor devuelto no es importante, sino el 
«efecto lateral» que se produce: 


devuelve «12», pero lo que nos interesa es que «Variable» tenga asignado, 
a partir de ahora, el valor «12». 

Otro caso curioso es aquél en que en una función se realizan varias ta- 
reas (varias evaluaciones): el intérprete devolverá el valor de la última eva- 
luación que haya realizado, pero son interesantes el resto de los efectos la- 
terales conseguidos. Así, si definimos (inmediatamente vamos a ver cómo 
se utiliza «DEFUN» para definir funciones): 


(DEFUN MA 
(DEFUI! 


IM 1VW1/A 11 


y llamamos a la función mediante la expresión: 


que es el resultado de la última evaluación (Z1 es igual al doble de Z), pero 
lo realmente interesante es que en X1, Y1 y Z1 están los valores dobles de 
2,3 y6. 

Otra situación en la que son importantes los efectos laterales se produ- 


Definición de funciones 


Como ya hemos comentado, una de las características que más valora 
el programador de LISP es la facilidad que existe en este lenguaje para de- 
finir funciones. 

Para definir una nueva función en LISP (adicional a las primitivas que 


mo, el «cuerpo» de la definición (es decir, la «descripción» de la función 
en lenguaje LISP). Por ejemplo, si en nuestro LISP no está definida como 
primitiva, la función ADD1 descrita anteriormente la podríamos definir así: 


Con ello LISP almacena el dato de que (ADD1 X) es lo mismo que (PLUS 
X 1). Del mismo modo podríamos definir: 


o bien, si previamente teníamos asignado a X el valor «Pedro» (bien por 
alguna evaluación anterior o como resultado de una SETO), se puede ha- 
cer, con el mismo resultado, 


6 


pa 


Nótese que en la definición de la función las variables deben ir entre pa- 
réntesis (formando una lista) y sin apóstrofos. A su vez, en el cuerpo de la 
definición las variables no deben ir entre paréntesis ni con apóstrofos (aun- 
que deben llevar apóstrofos los átomos que no queramos que se evalúen al 
«llamar» a la función). 

Aunque en la definición de la función las variables quedan sin ligar, 
cuando se llama a la función, hay que dar valores a los argumentos y en- 
tonces las variables de la definición se «ligan» a estos valores (temporal- 
mente; al concluir la evaluación de la función, se liberan de nuevo). 

Si queremos en cualquier momento ver cómo está almacenada una fun- 
ción que hayamos definido, podemos introducir el nombre de la función 
sin parámetros y obtendremos (en los dialectos más usuales, al menos) 
una definición del siguiente estilo: 


que, como se ve, es la definición de la función sin su nombre: en efecto, 
como definición de la palabra representativa de la función, LISP almace- 
na esta «lambda expresión». Una «lambda expresión» es una lista en la que 
aparecen los parámetros y una expresión LISP a evaluar con esos paráme- 
tros. Podríamos haber descrito anteriormente las «lambda expresiones» y 
haber dicho después que en la forma especial DEFUN se da un nombre a 
una «lambda expresión». 

Pero las «lambda expresiones» se pueden utilizar como tales dentro de 
un programa LISP cuando hay que realizar una labor repetidas veces y que- 
remos definir localmente una pequeña función para ejecutar esa labor: 
como sólo se va a usar en un lugar del programa no es necesario darle 
nombre y se usa una «lambda expresión» que es, en el fondo, como una 
función sin nombre, para ser usada localmente. (Piénsese que en progra- 
mas largos puede ser útil esta economía de nombres para evitar dupli- 
cidades y conseguir un pequeño ahorro de espacio.) 


== Control del proceso 


Para.la toma de decisiones dentro del programa se pueden utilizar va- 
rias «formas especiales» (es decir, una especie de función con estructura 
peculiar que no evalúa sus argumentos). 

Dependiendo del dialecto de LISP que esté usted utilizando dispondrá 
de unas funciones u otras. Vamos a comentar aquí las más usuales, aun- 


62 


que en su LISP existan otras a las que no aludiremos. Por supuesto, ya he- 
mos visto de qué forma sencilla se pueden definir funciones en LISP y, por 
tanto, usted podrá incluir estas funciones en su intérprete, si no las tiene 
ya disponibles. 


IF 


La condicional más sencilla de LISP es IF. Es una forma especial for- 
mada por una lista que tiene cuatro elementos: el primer átomo de la lista 
es la palabra IF; el segundo una expresión LISP que se evalúa para esta- 
blecer el control (es la «condición» del IF); a continuación aparecerán dos ' 
expresiones que son las que se evaluarán respectivamente si la condición 
se cumple o si no se cumple. Por ejemplo, 


devolverá (VALE UNO) si X tiene asignado un valor de «1» y devolverá 
(NO ES UNO) si X tiene asignado un valor distinto de 1. 

Se puede utilizar IF para definir, por ejemplo, una función (un predi- 
cado) que averigiie si un número es cero o distinto de cero, así: 


obtendremos como respuesta: 
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Si, por el contrario, introducimos: 


LISP devolverá: 


COND 


Otra forma especial muy útil para la toma de decisiones en un progra- 
ma LISP es el condicional COND. Tiene la estructura de una lista cuyo pri- 
mer átomo es, precisamente, COND y los restantes elementos (tantos cuan- 
tos se quiera poner) son parejas de términos (entre paréntesis) formados 
por dos elementos: el primero un predicado y el segundo una expresión 
LISP. Es decir, su estructura es: 


Para procesar esta expresión condicional, el intérprete va evaluando su- 
cesiva y ordenadamente los predicados hasta que encuentra uno que val- 
ga T (True, verdad); entonces evalúa la expresión correspondiente, devuel- 
ve ese valor y concluye el proceso. Sólo evalúa la expresión correspon- 
diente al primer predicado verdadero en la lista. 

Las expresiones de la derecha de las parejas anteriores pueden estar for- 
madas por toda una sucesión de expresiones (y no necesariamente sólo 
una): en ese caso se evaluarán todas las que aparecen a la derecha del pri- 
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mer predicado verdad, se ejecutarán (si es que tienen algún efecto lateral) 
y se devolverá el último valor evaluado, como siempre (o casi siempre). 

Naturalmente, si se introduce en COND una sublista tal que la cabeza 
de ella es un predicado que siempre se evalúa a «T», la evaluación no se- 
guirá jamás después de esta sublista, por lo que se puede omitir el resto 
de las sublistas que estén detrás. A veces se busca precisamente este efec- 
to: hay ocasiones en que es necesario programar un condicional del tipo 
«si Al, entonces Ml; si A2, entonces M2..., si AS, entonces M5 y, en caso 
contrario, M6». Esto se escribirá en LISP con una estructura como la si- 
guiente: 


Si alguno de los predicados Al hasta A5 es «T», LISP evaluará la se- 
cuencia correspondiente M1, M2..., M5 y, si ninguno es «T», ejecutará M6 
(pues «T» siempre es «T», claro). 


AND 


Esta es una función primitiva utilizada para establecer condiciones 
complejas. Significa «y». 

La función «AND» se evalúa del siguiente modo: se van tomando suce- 
sivamente cada uno de sus argumentos y se evalúan; si uno de ellos de- 
vuelve NIL, entonces se concluye la evaluación y la función AND devuel- 
ve NIL. Si ninguno devuelve NIL, AND devuelve el último argumento eva- 
luado. Esto puede producir sorpresas cuando se evalúan valores que no 
son predicados (funciones, variables, etc.) y que, por tanto, no devuelven 
ni «T» ni «NIL». Así, el resultado de 


_ AAA AAA 
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Si sabemos que X vale «1» e Y vale «3» y escribimos: 


LISP devolverá «T», pues para evaluar COND toma la primera sublista y 
dentro de ella la cabeza: (AND (EQUAL X 1) (LESSP Y 5)); si suponemos 
que «X» estaba ligado al valor 1 e «Y» a un valor menor que 5, como se 
cumplen ambas condiciones («una condición AND —Y— la otra») enton- 
ces, la cabeza de la lista se evalúa a «T» y se devuelve el resultado de eva- 
luar la cola de dicha sublista: «T». (De acuerdo con las condiciones de eva- 
luación de COND, no pasa a evaluar la segunda sublista (T NIL).) 


OR 


A semejanza de la anterior, OR se utiliza en la construcción de cláusu- 
las de condición complejas. Hay que interpretarla como una disyunción 
(«0»). Se evalúa de tal modo que si cada argumento va dando valor NIL, 
sigue la evaluación: al final se devuelve valor NIL. Si, por el contrario, al- 
guno de los argumentos devuelve un valor distinto de NIL (un valor alfa- 
numérico o bien «T» si se trata de predicados), cesa la evaluación y se de- 
vuelve el último valor evaluado. Por ejemplo, 


2 A 


dará valor «T», pues es ése el valor que se obtiene en la evaluación de 
(LESSP 2 5). Pero, 
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dará una respuesta de 


Z, 


OT 


También se puede incluir en las expresiones condicionales complejas 
el predicado NOT, del que ya hemos hablado. 

Por otro lado, normalmente (depende de los dialectos) no hay proble- 
ma en establecer condiciones complejas con todas estas primitivas condi- 
cionales mezcladas (o, incluso, apareciendo alguna de ellas varias veces). 
Así, por ejemplo, la respuesta a 


será NIL. 


Por otro lado, existen varias primitivas que permiten establecer una 
cierta estructuración permanente del programa. Básicamente se pueden 
reseñar dos grupos: uno primero formado por las primitivas básicas de es- 
tablecimiento de bucles (suele haber, en cada dialecto de LISP, al menos 
una de ellas) y son las primitivas LOOP («lazo» o «bucle»), REPEAT («re- 
pite»), DO («haz»), etc.; otro grupo es el que incluye a WHILE («mientras»), 
UNTIL («hasta») y equivalentes, que controlan el final del bucle. 

Las primitivas LOOP, REPEAT, etc., proporcionan un procedimiento 
de establecer un bucle: aunque la sintaxis concreta varía con cada dialec- 
to, normalmente suelen tener después del nombre una condición (y una 
asignación de variables locales en el caso de «DO») y a continuación un 
conjunto de expresiones a evaluar repetitivamente con los valores de las 
variables, hasta que se cumpla la condición de terminación indicada al 
principio. 

Esta condición se suele establecer con las primitivas WHILE («mien- 
tras») o UNTIL («hasta»), que hacen que el proceso se repita «mientras» se 
cumpla una determinada condición o precisamente «hasta» que esa con- 
dición se dé. 
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REFERENCIA ADICIONAL DE PRIMITIVAS 


Aunque con las primitivas ya descritas se pueden preparar pequeños 
programas en LISP, la capacidad del lenguaje es mucho mayor. Entende- 
mos que rebasa los límites de esie libro la discusión de las técnicas sofis- 
ticadas de programación en LISP y, además, para profundizar más en al- 
gunos aspectos de dichas técnicas deberíamos referirnos a alguno (o algu- 
nos) de los numerosos dialectos existentes (algunos no disponibles en or- 
denadores personales). Creemos, sin embargo, que puede ser útil para 
completar el panorama que hemos presentado del lenguaje, a modo de in- 
troducción a la programación en LISP, la descripción de algunas de las pri- 
mitivas más usuales no comentadas aún, insistiendo en que los detalles 
concretos de la sintaxis en el dialecto o versión de LISP de que usted dis- 
ponga, deberá consultarlos en el manual concreto que le ha facilitado el 
fabricante del intérprete correspondiente. 


Otros predicados interesantes 

Suelen existir implementados en cualquier intérprete de LISP varios 
predicados (aparte de los ya reseñados) sumamente útiles. 
NULL 


Comprueba si el argumento (sólo uno) que se le da es NIL o no. 
Por tanto, devolverán valor T las siguientes expresiones: 


ATOM 


Devolverá valor T si el objeto que se le pone como argumento (uno 
solo) es un átomo. Por ejemplo, 


LISTP 


Averigua si el objeto que tiene como argumento es una lista. Es decir, 
será T: 


NUMBERP 


Comprueba el tipo del objeto y devuelve T si es un número: 


BOUNDP 


Devuelve el valor T si la variable que se le da está ligada («bounded» 
en inglés). Por ejemplo, 


¡NRGUNTIP "PEDE 
DUOUNDFr FEE) 


MAKUNBOUND 
No es propiamente un predicado, sino una función que hace que la va- 


riable que se da como argumento deje de estar ligada («making unbound», 
en inglés). No todos los dialectos disponen de esta primitiva. 


SYMBOLP 


Devuelve T si el argumento que se le da es, precisamente, un símbolo 
(y no un número). 
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Primitivas de manejo de listas 


ASSOC 


Se utiliza para localizar datos en una lista «larga» (una base de datos). 
La base de datos debe tener la estructura de sublistas y estar formada cada 
una de estas sublistas por dos elementos: la cabeza de la lista como iden- 
tificador y el resto de la lista (cola) como conjunto de datos. Si se asocia 
SETO) la base de datos a un identificador (sea este «DATOS», por ejem- 
plo) la introducción de 


am, 


buscará en la lista de DATOS (la «base de datos») una sublista cuya cabeza 
sea el «identificador» y devolverá el resto de la sublista como una lista. 


NTH 


Es un selector que extrae el n-simo elemento de una lista. (A veces ex- 
trae el CDR de la lista desde el n-simo elemento; vea el manual del dialec- 
to LISP que esté usted utilizando.) 


NTHCDR 


Es una función que devuelve el n-simo CDR de la lista que se le da. Tal 
como acabamos de comentar, hay dialectos en que esta función es la rea- 
lizada por NTH. En cualquier caso, la combinación de la primitiva adecua- 
da (NTH o NTHCDR) con CAR o CDR (según los casos) permite ir extra- 
yendo elementos de la lista. 


REVERSE 


Devuelve la lista «inversa» de la lista que se le da. Es decir, se le da una 
lista y la devuelve con los elementos ordenados de un modo inverso a la 
lista original. 
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APPEND 


Reúne en una sola lista los elementos de dos listas distintas. En algu- 
nos dialectos se pueden reunir, en una sola operación de «append», varias 
listas. 


LENGTH 


Devuelve la longitud de la lista que se le da. Hay varios dialectos que 
tienen esta función bajo el nombre LEN. 


EXPLODE 


Produce una lista con los diferentes caracteres de un átomo. Así, si se 
introduce 


LISP devolverá 


IMPLODE 


Devuelve un átomo reuniendo todos los elementos (átomos) de una lis- 
ta. Es la función inversa de la función EXPLODE. Así, el resultado de 
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a 


IN 


Primitivas de entrada/salida 


Para las funciones de entrada y salida suele estar disponible en LISP 
un conjunto de primitivas muy variado: en efecto, estas funciones son más 
dependientes aún del equipo y de la versión de intérprete utilizada que el 
resto de funciones a que hemos aludido. 

Para la impresión de datos suele estar presente la primitiva PRINT y al- 
gunas variantes; y para la introducción de datos la función READ. Es muy 
normal tener que «abrir» (OPEN) un dispositivo antes de leer o escribir en 
él, para «cerrar» (CLOSE) al concluir la lectura o escritura de datos. 

Además, para guardar los programas que hayamos podido preparar, las 
asignaciones de variables realizadas, etc., tendremos, normalmente, que 
utilizar la primitiva SAVE o similar; y para «cargar» en memoria un pro- 
grama y el estado del área temporal en que el programa estaba operando, 
se suele disponer de la función LOAD. 


TIPOS Y DIALECTOS DE LISP 


Teniendo en cuenta que LISP es uno de los más antiguos lenguajes de 
alto nivel (¡junto con FORTRAN), no es de extrañar que existan numerosas 
versiones y dialectos del lenguaje. Además, hasta hace una década tuvo 
una extensión muy limitada estando reducida a ciertos ambientes univer- 
sitarios y de «laboratorios» de investigación en informática. Sólo moder- 
namente, con el desarrollo de las técnicas de Inteligencia Artificial, ha 
vuelto a tener interés comercial el lenguaje y se ha abordado el problema 
de la compatibilidad y transportabilidad entre los «diferentes LISP's» exis- 
tentes. 

Por otro lado, la compatibilidad se complica con la existencia de «má- 
quinas LISP»: es decir, no sólo existen numerosas versiones para que se 
utilicen sobre diferentes ordenadores de propósito general, sino que se 
han desarrollado máquinas concebidas para ser programadas en LISP: esto 
significa que se desciende a nivel de microcódigo para aprovechar hasta 
el extremo las capacidades de la propia máquina y del lenguaje, pero esto 
significa, por otro lado, que se introducen «peculiaridades» útiles para op- 
timizar las características del lenguaje que se obtiene. 

En el último lustro las empresas que tenían desarrollados intérpretes 
de LISP, o iban a desarrollarlos, han enfrentado el problema de la porta- 
bilidad de sus intérpretes, por lo que han proliferado las versiones de LISP 
escritas en C y otros lenguajes evolucionados. 

Todo ello ha producido un abanico enorme de dialectos y versiones de 
LISP, así como «sistemas LISP» formados por la integración de los intér- 
pretes de LISP con otras «herramientas» de programación como intérpre- 
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tes de PROLOG u otros lenguajes y manejadores de los entornos adecua- 
dos. Dentro de este mundo de dialectos y versiones se ha intentado (bajo 
directrices del Departamento de Defensa de los EE.UU., verdadera «loco- 
motora» y financiador de numerosos proyectos en este área) construir un 
estándar: así ha nacido el CommonLISP pero, hasta el presente, está lejos 
de conseguirse esa unificación de los dialectos de LISP. 

Lo que sí es cierto es que la estructura básica del lenguaje se mantiene 
y hasta un cierto «estilo de programación» LISP. Al pasar de un dialecto a 
otro cambian funciones básicas (desde DEFUN hasta PROG, etc.) e, inclu- 
so, cosas tan elementales como la respuesta de las primitivas CAR o CDR 
al átomo NIL. Pero, por otro lado, cualquier persona que conozca la pro- 
gramación básica en LISP (en cualquier LISP no muy específico) puede, 
a la vista del manual de referencia del suministrador del software, detec- 
tar las diferencias existentes y adaptar su programación al dialecto dispo- 
nible (otra cosa son los programas ya hechos para otro dialecto). 

En lo que sigue vamos a comentar algunos de los dialectos LISP dis- 
ponibles hoy en el mercado, fijandonos básicamente (aunque no exclusi- 
vamente) en los que se utilizan en las máquinas de propósito general, no 
muy grandes y ordenadores personales, que son los que más interesarán 
a los lectores de este libro. 


MAC LISP 


Una de la primeras versiones LISP comercializadas extensamente fue 
el MacLISP del PDP-6. Esta versión fue escrita en el MIT ( «Massachusetts 
Institute of Technology») en la mitad de los años sesenta. Posteriormente, 
en la Universidad de Stanford se mejoró y aumentó la versión de MacLISP 
de que disponían en su PDP-6, creando una versión más adaptada al en- 
torno DEC, que nombraron LISP 1.6 y que fue conocida, también, como 
el LISP de Stanford. 

En la Universidad de California (en Irvine) prepararon una modifica- 
ción de este «Stanford LISP» y lo bautizaron con su nombre: UCI, LISP. 
Allí mismo (en UCI) se desarrolló posteriormente el BBN LISP, que es el 
mismo UCI LISP mejorado con la inclusión de varias «herramientas» de 
programación (paquete de edición, paquete de desarrollo...). Este es el que, 
posteriormente mejorado se conoce como InterLISP. 

Sin embargo, por su cuenta, siguió desarrollándose MacLISP, y ya en 
1972 John L. White lo reescribió para PDP-10 e, incluso, en los años ochen- 
ta, está en uso en numerosas instalaciones de DEC-20. Una característica 
muy interesante de MacLISP es que cuenta con un amplio sistema «runti- 
me» (es decir, no para desarrollo, sino para ejecución final) que incluye 
un intérprete escrito en Ensamblador. Este sistema «runtime» es grande 
(su listado ocupa unas 600 páginas) y, por tanto, eficaz. 
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Una de las características más sobresalientes de MacLISP es su eficacia 
en el manejo de números y operaciones aritméticas. En MacLISP para im- 
primir una función se usa la primitiva GRINDEF: úsela si usted trabaja en 
MacLISP y duda cómo está definida alguna función. MacLISP ha sido un 
clásico entre los dialectos de LISP y, de hecho, ha sido durante muchos 
años el punto de referencia para otros dialectos en cuanto a compatibili- 
dad, rapidez de ejecución, facilidades, etc. Además, ha sido sobre MacLISP 
como se han desarrollado otros dialectos como NIL, Spice Lisp, Zetalisp, 
S-1 Lisp, Frazlisp, etc. 

La sintaxis de Lisp-Machine LISP y de CommonLISP es semejante a 
ésta (excepto que CommonLISP no acepta FEXPR). 


ZETALISP 


Es un dialecto obtenido a partir de Lisp-Machine LISP del MIT. Este úl- 
timo dialecto es el resultado del proyecto del MIT sobre la «Lisp Machi- 
ne». Posteriormente han sido dos compañías comerciales (Symbolics Inc. 
y Lisp Machine Inc. —LMI—) quienes han comercializado dos versiones 
de la máquina CADR desarrollada en el MIT en el proyecto a que estamos, 
aludiendo. Pero tanto, estas versiones comerciales (LMI CADR y Symbo- 
lics LM2) como la máquina LISP del MIT (MIT CADR) ruedan el mismo 
LISP, que actualmente es el ZetaLISP. 

Sus características básicas vienen definidas por las máquinas en que 
está soportado: hacen un amplio uso de microcódigo, poseen un direccio- 
namiento en memoria virtual a dos niveles, disponen de una memoria ex- 
tensa, etc. Es especialmente eficaz en la llamada de funciones (por el so- 
fisticado sistema de llamadas invertidas, de que ha sido dotado) y en el ma- 
nejo de números en coma flotante. 


FRANZ LISP 


Fue escrito por Richard Fateman y su equipo en la Universidad de Ca- 
lifornia (Berkeley). Aunque en principio fue desarrollado con la finalidad 
concreta de hacer ejecutable sobre VAX una versión específica del siste- 
ma MACSYMA (Sistema experto utilizado en el aprendizaje de las matemá- 
ticas), ha llegado a ser una de las versiones de LISP más disponible sobre 
máquinas que operen bajo UNIX. 

En FRANZ LISP las primitivas están escritas en minúsculas. La defini- 
ción de funciones se hace, como er. MacLISP, mediante la primitiva DE- 
FUN («defun» en FRANZ LISP), aunque dispone de otra forma especial, lla- 
mada «def». El listado de una función se hace mediante «pp». El núcleo de 
Franz LISP está escrito casi enteramente en lenguaje C. Es bastante flexi- 
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ble en cuanto al soporte de arrays y estructuras definidas por el usuario, 
aunque no admite la programación orientada al objeto ni la definición de 
«tipos abstractos de datos». 


INTERLISP 


InterLISP es una versión ampliada del BBN LISP desarrollado en la 
Universidad de California (Irvine). Básicamente, las mejoras vienen en el 
sentido de incluir cantidad de módulos de utilidad que ayudan en la pro- 
gramación, en la edición, en el manejo de archivos, etc. En InterLISP no 
se manejan las «macros» en el sentido usual de este término, sino que for- 
man parte del programa solamente en el momento de la compilación. El 
listado de funciones se hace en InterLISP mediante la primitiva «pp». 

La versión más conocida de este dialecto es la ofrecida por XEROX: In- 
terLISP-D. Lo que aporta, básicamente, InterLISP-D es un entorno, sofis- 
ticado y sumamente cómodo, de programación: las funciones del usuario 
pueden pasar al entorno y viceversa; las herramientas de desarrollo son nu- 
merosas: se manejan muy cómodamente los ficheros de programas, desde 
ventanas; hay editores, un «inspector» (para el examen de estructuras com- 
plejas de datos), un «masterscope» (para analizar los programas del usua- 
rio), etc. XEROX propone con su InterLISP-D la realización de lo que Sheil 
(1983) introdujo como «programación por exploración»: es decir, el ir des- 
arrollando el programa definitivo mediante aproximaciones sucesivas, 
añadido de otros elementos, reforma de los existentes, etc. 


COMMON LISP 


Tal como se ha comentado, intenta ser un estándar de LISP y para los 
equipos no muy especializados (ordenadores personales y estaciones de 
trabajo utilizadas en entornos de programación de Inteligencia Artificial) 
lo va consiguiendo. 

Existen numerosas implementaciones de él, y como la mayoría de ellas 
aportan alguna característica especial (aparte de la implementación del 
COMMON LISP en sí) se suelen nombrar dándole «su apellido»: VAX Com- 
mon LISP (que rueda en todos los modelos VAX de Digital E.C. bajo el sis- 
tema Operativo VMS), Data General Common LISP (que rueda en la gama 
completa de los ordenadores de esa firma con arquitectura MV y bajo los 
sistemas operativos AOS/VS y MV/UX)... y el más popular, Golden Com- 
mon LISP (desarrollado por Golden Hill para los ordenadores PC de IBM 
o compatibles, bajo sistema operativo MS/DOS). 

Este Golden Common LISP entendemos que es el más interesante para 
los usuarios de ordenadores PC compatibles, pues es el más extendido a 
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este nivel y aporta un conjunto de «facilidades» adicionales muy útiles: el 
editor GMACS (entorno de desarrollo con múltiples buffers, ventanas, 
identificación automática del código, etc.), un sistema de ayuda en línea 
(utilísimo en desarrollo), facilidades de gráficos, etc. 

En esta misma línea de intérpretes de LISP no muy sofisticados (aun- 
que suficientemente potentes), para su uso en ordenadores personales, po- 
demos reseñar los siguientes: 


MULISP 


Aporta una buena capacidad para la definición (por parte del usuario) 
de estructuras de datos complejas (maneja tres objetos de datos primiti- 
vos: nombres, números y nodos) y dispone de numerosas primitivas para 
la eficaz utilización de estas estructuras. Se presenta con numerosos ejem- 
plos y un curso «tutorial» para el fácil aprendizaje. 


BYSOLISP 


Es compatible con MacLISP y con LISP 1.5. Maneja archivos secuen- 
ciales, pero no de acceso directo. Maneja listas, símbolos (átomos) y algu- 
nos tipos de números. También maneja estructuras de datos definidas por 
el usuario. Es un intérprete que se facilita sin protección y a un coste no 
muy elevado. Aunque no es muy potente y la documentación que aporta 
es un poco pobre, es una magnífica herramienta para empezar a progra- 
mar en LISP. 


WALTZ LISP 


Está basado en Franz LISP. Es bastante compatible con la mayoría de 
los dialectos de LISP que ruedan bajo sistema operativo UNIX. La mayor 
deficiencia de Waltz LISP es que no maneja números en coma flotante, 
aunque soporta listas y símbolos (átomos). Maneja archivos secuenciales 
y también archivos de acceso aleatorio y todas las funciones de directo- 
rios del PC-DOS. Es bastante rápido e incluye una versión de PROLOG 
(Clog Prolog) un poco lenta, pero interesante. Se facilita una buena docu- 
mentación. 


XLISP 


Es una versión muy útil de LISP (sus autores la definen aún como «ex- 
perimental») que combina las capacidades básicas del lenguaje con las ca- 
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racterísticas necesarias para realizar programación orientada al objeto (es- 
tán definidas en XLISP las primitivas «Object» —objeto— y «Class» —cla- 
se— con esta finalidad). Está escrito completamente en C y se facilita el 
lenguaje fuente para que pueda ser ampliado o adaptado por el usuario. 
La documentación es un poco pobre, pero suficiente. Aunque las prime- 
ras versiones estaban basadas en MacLISP (sin llegar a ser compatible), en 
la versión 1.4 ya se introducen algunas funciones de Common LISP y los 
autores manifiestan su intención de llevar XLISP a ser compatible con 
Common LISP, en versiones futuras. 


EA 


Y 
YO 
O 
ES 
O 
C) 


PRESENTACION DE PROLOG 


E entre los lenguajes hoy disponibles para aplicaciones de 
Inteligencia Artificial es necesario destacar el PROLOG 
como una de las herramientas fundamentales en los des- 
arrollos prácticos. Existen numerosas versiones de este 
lenguaje y hasta las compañías que defendían hace cinco 
años el uso de LISP (a veces en exclusiva), están incorpo- 
rando hoy a sus máquinas y entornos de programación el 
=== PROLOG. 

Hay que señalar dos datos básicos que marcan el enor- 
me desarrollo que está teniendo el lenguaje PROLOG en los últimos años: 
por un lado, es un lenguaje muy apropiado para los sistemas de inferencia 
que están en la base de la mayoría de las aplicaciones de Inteligencia Ar- 
tificial; de hecho, los dos lenguajes de programación más utilizados en este 
área son LISP y PROLOG, y los entornos más sofisticados que se están des- 
arrollando en los últimos años se basan en alguno (o ambos) de estos dos 
lenguajes. Por otro lado, el PROLOG ha sido tomado como base del (de 
los) lenguaje(s) de programación a desarrollar en el proyecto japonés «del 
ordenador de la quinta generación». 

¿Quiere esto decir que PROLOG va a ser el lenguaje de programación 
del año 2000? Esto es difícil de contestar, pero lo que parece claro es que 
PROLOG o algún dialecto de él será un lenguaje básico en los ordenado- 
res que en esa fecha estemos utilizando. 

Y ¿por qué PROLOG precisamente y no otro lenguaje de programa- 
ción? Ya hemos comentado que no es sólo PROLOG el lenguaje a utilizar 
en Inteligencia Artificial, sino uno de los posibles. Todos ellos tienen una 
característica especial: son lenguajes declarativos y no procedurales. Esto, 
como veremos con detalle más adelante, supone varias ventajas prácticas, 
además de la facilidad general que aporta para la representación del co- 
nocimiento y el proceso de la información en tareas de inferencia; estas 
ventajas son que cada porción de un programa (cada proposición o con- 


T3 


junto de ellas) es evaluable independientemente del resto y, por otro lado, 
que las modificaciones son fáciles de realizar, precisamente por esta inde- 
pendencia de cada proposición. 

_El concepto de lenguaje declarativo (en contraposición a los lenguajes 
procedurales) responde a la idea de facilitar al ordenador la información 
de que disponemos (algo estructurada, claro está) y dejar que él la maneje 
para obtener los resultados que deseamos, en vez de tener que concebir 
nosotros el procedimiento de cálculo (algoritmo) y explicárselo al orde- 
nador, como se hace en los lenguajes convencionales. 

En concreto en PROLOG, lo que realizamos es «programación lógica» 
(PROLOG = PROgraming LOGic): un programa en PROLOG es un conjun- 
to de proposiciones lógicas que el intérprete es capaz de manejar. PRO- 
LOG supone, de hecho, un conjunto de tres elementos: un lenguaje de re- 
presentación del conocimiento, una máquina de deducción y una verda- 
dera metodología de programación. 

Es cierto, en efecto, que en un principio fue concebido este lenguaje 
por Alain Colmerauer y Philippe Roussel (1972) como un lenguaje para re- 
presentar los razonamientos lógicos e implementar el recientemente ob- 
tenido «principio de resolución» (propuesto por Alan Robinson como mé- 
todo de demostración automática de teoremas). Sin embargo, con poste- 
rioridad se ha desarrollado enormemente el lenguaje y se han mejorado 
sus prestaciones para su utilización en aplicaciones prácticas (especial- 
mente sistemas expertos y procesamiento del lenguaje natural), conservan- 
do su estructura general y sus cualidades. 

La programación en PROLOG ha pasado de ser una mera «programa- 
ción lógica» a ser una programación con una estructura lógica de repre- 
sentación y proceso de los conocimientos: el modo de representar las in- 
formaciones en un programa escritc en PROLOG es una manera «más ló- 
gica» y «más natural» y marca, en consecuencia, todo un estilo de progra- 
mación y una verdadera metodología de concebir y plasmar los problemas 
para su óptima resolución. 

Pero en PROLOG, además de tener un sistema de representación del 
conocimiento muy cómodo y eficaz y una estructura de programación muy 
próxima al pensamiento humano, tenemos una verdadera máquina de de- 
ducción; en el propio intérprete se incluye un sistema de inferencia lógica 
que permite obtener datos y sacar conclusiones nada más formular nues- 
tro conocimiento en aseveraciones y relaciones. 

Por ejemplo, podemos decirle que Carlos I fue el padre de Felipe Il y 
que Felipe el Hermoso fue padre de Carlos I; si, además, le decimos que 
el «padre del padre de alguien» es el abuelo de esa persona, podemos in- 
mediatamente pasar a preguntarle si Carlos I es padre de alguien, si Felipe 
el Hermoso es abuelo de alguien, quién es el padre de Felipe II, etc., y el 
propio sistema hará sus «cálculos» y nos contestará. (Por el contrario, en 
un lenguaje más convencional —el popular BASIC, por ejemplo— habría 
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que definir las variables, teniendo cuidado con su tipo y definir cómo po- 


obviamos.) 


Además, otra ventaja de PROLOG es que su sintaxis es muy cómoda y 
sencilla, y que sus expresiones son casi como en castellano. Más concre- 
tamente, podemos construir una «base de datos» en PROLOG(*) introdu- 
ciendo las siguientes proposiciones: 


ms 5 
estCariosi essaDuecio-de Tenpelt) 


A o 115 
esírFrelnipeH es:abuelo:de Felpell) 


A pl + 
amen tx" xes:abuelo:de Felpell): 


pe II»; es decir, ¿quién es el abuelo de Felipe II?). 
Las respuestas a estas tres preguntas son evidentes para una persona 
cualquiera, pero ¿cómo trabaja PROLOG? Para aclararlo, vamos a intro- 


* El ejemplo que sigue está escrito en una versión castellana de micro-PROLOG que, aun- 
que no sea muy utilizable en general, sirve para esta primera presentación: volveremos a ha- 
blar en detalle de las versiones disponibles de PROLOG y micro-PROLOG. 


3 


pu 


ducir alguna proposición más a nuestra base de datos (con Margarita de 
Parma, hija natural de Carlos 1 y su hijo Alejandro Farnesio, que sucedió 
a Juan de Austria como gobernador de los Países Bajos, con Isabel Clara 
Eugenia, hija predilecta de Felipe II, regente (pero no gobernadora) de los 
Países Bajos y con el propio Juan de Austria, también gobernador de los 
Países Bajos): 


(obsérvese que han aparecido una nueva relación, el predicado «es-madre- 
de» y dos predicados adicionales: «fue-gobernador» y «fue-regente»). 

Además, debemos completar la definición del abuelo con el nuevo pre- 
dicado aparecido («es-madre-de»), quedando: 


Si ahora queremos saber quién fue una persona cuyo abuelo fue Car- 
los I y fue gobernador de los Países Bajos, preguntaremos: 


PROLOG procesará nuestra pregunta de izquierda a derecha e intenta- 
rá averiguar quién cumple la primera condición indicada: Carlos] es-abue- 
lo-de x. Para ello accede a las reglas de inferencia de que dispone y ve que 
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esa condición es equivalente a que se cumpla una cualquiera de las dos si- 
guientes (nuevos subobjetivos a obtener): 


Carlosl es-nad 7 Y EeS-DAd 


lra.de vw ¿ as-nadre-de 7 
¡US1 ECITPATiuUt y DOE y ECITPavitiut 


Toma la primera de ellas y ve, en la base de datos, si hay algún elemen- 
to «y» que cumple esta primera condición; hay tres: Felipe II, Juan de Aus- 
tria y Margarita de Parma; averigua si el primero de ellos (el primer valor 
«y» correspondiente a un hijo de Carlos I) cumple la segunda condición: 
en efecto «Felipell es-padre-de IsabelCE». Por tanto, ya tenemos un ele- 
mento x que cumple Carlosl es-abuelo-de x. Pero, desgraciadamente, Isa- 
belCE no cumple la segunda condición que imponemos en la pregunta, 
pues no fue gobernadora de los Países Bajos. Entonces PROLOG tiene que 
volver atrás (backtracking se llama el proceso) para seguir con alguno de 
los casos posibles que ha desechado anteriormente. 


Toma entonces la segunda opción (JuanA) que cumplía «Carlosl es-pa- 
dre-de y», pero este elemento no cumple «y es-padre-de z», pues en la base 
de hechos no aparece JuanA como padre de nadie. 


Carlos Lia 
E A 


Fig. 1. Descendientes de Carlos 1. 
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Fig. 2. Proceso de Backtracking. 
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Así, vuelve (backtrack) a Margarita de Parma que había cumplido la pri- 
mera condición impuesta: Carlos] es-padre-de y. Para este nuevo valor de 
«y», preguntamos por la segunda parte de las condiciones impuestas como 
subobjetivos en (1) y vemos que MargaritaP no cumple tampoco, pues 
«MargaritaP es-padre-de z» no es cierto para ningún z. Esta rama del pro- 
ceso se ha agotado sin éxito y hay que volver atrás (backtracking) pregun- 
tando por la segunda opción (subobjetivo) de las previstas en (1). Ahora 
PROLOG verá que «Carlosl es-padre-de MargaritaP» y «MargaritaP es-ma- 
dre-de AlejandroF» (habiendo comprobado y desechado «Carlosl es-padre- 
de Felipell» y «Carlosl es-padre-de JuanA», pues ninguno de los dos cum- 
ple «y es-madre-de z»). 

Con este nuevo valor obtenido comprueba la segunda condición de la 
pregunta inicial y ve que, en efecto, Alejandro Farnesio fue gobernador de 
los Países Bajos; entonces PROLOG contesta: 


y como, después de las oportunas comprobaciones y vueltas atrás, descu- 
bre que no hay ningún otro elemento que responda a la pregunta, añade: 


Estos conceptos son los que el propio Colmerauer (*), coinventor del 
PROLOG, sintetiza en lo que llama el «reloj del PROLOG» (o máquina del 
PROLOG) y que aparece en la figura 3. 


En ella, «i» contiene un número no negativo que representa el 
tiempo. 
«Ci» contiene las restricciones (o condiciones) que deben 
ser satisfechas en el tiempo (momento) «i». 
«Ti» incluye la secuencia de términos que no han sido eli- 
minados aun en el momento «i». 
«Ri» es el número de la regla elegida en el tiempo «i». 


* «Proceedings of the Eighth International Joint». Conference on artificial Inteligence. 


Karlsruhe. W. Germany. Tomo 1, pág. 496. 
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Fig. 3. El reloj del PROLOG. 


«Rmax» indica el número de la última regla. 

«la parte más relevante de Ci» significa la subcondición (en 
forma reducida) que se refiere a las variables que apa- 
recen en la pregunta. 


El funcionamiento de la máquina viene descrita por los dos círculos 
de la figura 3. En el exterior, el proceso gira una vuelta en el sentido de 
las agujas del reloj, mientras el tiempo («i») se incrementa en una unidad; 
en el interior se produce un giro en sentido contrario a las agujas del re- 
loj, mientras el tiempo decrece una unidad. Se puede cambiar la progre- 
sión del tiempo pasando de uno a otro a través de uno de los dos «puen- 
tes» de un solo sentido que hay uniendo ambos círculos. 

La ejecución de un programa PROLOG consiste en responder a una pre- 
gunta representada por un término (al principio se almacena en To). To- 
das las respuestas que se van computando son restricciones o condiciones 
en las cuales el término representa hechos específicos. Comenzamos el 
proceso por el par (Co, To); Co está vacío y To es la pregunta de comien- 
zO. Cada vuelta que se da al círculo exterior incrementa la condición vi- 
gente actualmente «Ci» y transforma la secuencia «Ti». Si la regla que se 
utiliza ya contiene una condición B, esta condición se añade al juego de 
condiciones elementales de que disponemos. Concluye el proceso en cuan- 
to se genera una condición no satisfecha o cuando la secuencia «Ti» que- 
da vacía: es el momento en que se realiza el paso de backtracking (vuelta 
atrás) para tomar otras reglas. Si en algún momento, durante el proceso 
de giro del «reloj», «Ci» es satisfactorio, se imprime la respuesta (y vuelve 
atrás para localizar respuestas adicionales). 

Para concluir esta breve introducción a PROLOG incluimos un progra- 
ma escrito en el dialecto más popular de los existentes para microordena- 
dores pequeños (el microPROLOG) y referente al «análisis» de una «base 
de hechos» geográfica (*). 


a) Se utilizan las relaciones: 


referidas estas posiciones a su situación en un mapa imaginario. Como 
nombres de individuos se utilizarán las capitales de las provincias, las pro- 


* Inspirado en el manual del micro-PROLOG preparado por K. L. Clark, F. G. McCabe 
y J. R. Ennais. 
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vin 


cias de tres autonomías españolas y estas tres autonomías (Asturias, Rio- 


ja y País Vasco). 


b) La base de datos podría ser: 


Oviedo capital-de Asturias 

Bilbao capital-de Vizcaya 
SSebastian capital-de Guizpuzcoa 
Vitoria capital-de Alava 

Logroño capital-de Rioja 

Vizcaya provincia-de PaisVasco 
Guipuzcoa provincia-de PaisVasco 
Alava provincia-de PaisVasco 
Asturias provincia-de AsturiasAut 
Rioja provincia-de RiojaAut 
Oviedo situacion (15 5) 

Bilbao situacion (16 12) 
SSebastian situacion (17 15) 
Vitoria situacion (13 13) 
Logroño situacion (11 14) 


c) Con todo esto, podríamos formular preguntas del tipo: 


1. ¿Qué ciudades están al norte de Vitoria? 


Wich (x : x situacion (y z) and Vitoria situacion (Y Z) and Y LESS y) 
o bien en la versión castellana de microPROLOG: 
que (z : z situación (x y) e Vitoria situación (X Y) e X es menor que x) 


(Nótese que en la versión castellana del microPROLOG de Spectrum la co- 
nectiva lógica «and» se ha traducido por «e» en vez de «y», para no con- 
fundirla con esta variable.) 


2. ¿Hay alguna provincia del País Vasco cuya capital esté al Norte de Lo- 
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groño y al Sur de Oviedo? 

is (x provincia-de PaisVasco and y capital-de x and y situacion (z X) and 
Logroño situacion (Y Z) and Oviedo situacion (x1 y1) and Y LESS z 
and z LESS x1) 


o en castellano: 


¿x provincia-de PaisVasco e y capital-de x e y situacion (z X) e Logroño 
situacion (Y Z) e Oviedo situacion (x1 y1) e Y es-menor-que z e z es-me- 
nor-que x1) 


3. ¿En qué ciudad y autonomía hay una ciudad al sur y al este de Bilbao? 


wich (x y : x provincia-de y and z capital-de x and z situacion (X Y) and 
Bilbao situacion (Z x1) and X LESS Z and x1 LESS Y) 


y en castellano: 


que (x y : x provincia-de y e z capital-de x e z situacion (X Y) e Bilbao 
situacion (Z x1) e X esmq Z e x1 esmq Y) 


(utilizando la abreviatura «esmq» en vez de la frase completa es-menor- 
que). 


FUNDAMENTOS DE PROGRAMACION EN PROLOG 


Vamos a examinar ahora con más detalle los elementos constitutivos 
del lenguaje PROLOG y los conceptos de base de la programación lógica 
en general y de la programación con PROLOG en particular. Para los ejem- 
plos que vayan apareciendo utilizaremos la sintaxis que proporciona el 
«traductor» SIMPLE incluido en el intérprete de micro-PROLOG (igual que 
se ha hecho en la introducción de este capítulo). Esta sintaxis es más sen- 
cilla, lo que permite al lector no experto centrarse en los conceptos, sin 
dificultades de lectura de los programas. No se utilizará la versión caste- 
llana a partir de aquí porque no está disponible en todos los microorde- 
nadores usuales y entendemos que sería muy útil que el lector fuera intro- 
duciendo en su ordenador los ejemplos que le ofrecemos, para aclarar con- 
ceptos y para que se vaya familiarizando con el lenguaje, su sintaxis y el 
modo de programar con él en su microordenador; la versión original de 
SIMPLE, por otro lado, sólo requiere memorizar una decena de palabras 
inglesas. Hablaremos después de cómo crear fácilmente una versión cas- 
tellana de SIMPLE, de la sintaxis estándar del micro-PROLOG, de las dife- 
rentes versiones existentes de PROLOG, etc. 
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Elementos constitutivos del programa 


Un programa PROLOG es un conjunto de aseveraciones o frases que 
contienen información. Es como una base de conocimientos organizada 
en forma de sentencias individuales. 

Los elementos básicos constitutivos de estas frases o proposiciones son 
los «objetos», las «propiedades» y «relaciones», y las conectivas lógicas que 
realizan la ligazón de los anteriores elementos. 

Las frases o proposiciones sencillas son simples aseveraciones en que 
aparece(n) un(os) sujeto(s) y algo que se dice de ese(esos) sujeto(s) (a esto 
que «se dice» del o de los sujetos se designa en lógica con el nombre de 
«predicado»). Estas frases constituyen los «hechos» del programa. Por 
ejemplo: 


En el primer caso, aparece un sujeto («la-casa») y una propiedad que 
se le atribuye (el predicado monádico o unario «es-grande»); en la segun- 
da frase aparecen dos sujetos («la-casa» y «el-río») y en medio una relación 
(el predicado diádico o binario «está-a-la-derecha-de»); en la tercera, tres 
sujetos («la-casa», «el-río» y «la colina») y otra relación (otro predicado 
—poliádico también— «está-entre»). 


Desde el punto de vista formal, las propiedades (un predicado con un 
sujeto) y las relaciones (un predicado con varios sujetos) reciben el mis- 
mo tratamiento: en conjunto se les llama «relaciones». Se admite incluso 
una relación sin sujetos. En cuanto a los «sujetos» de estas frases, se sue- 
len llamar en PROLOG «elementos» O «argumentos»; a veces, también, 
«Objetos». Los elementos pueden ser simples y compuestos. Los elemen- 
tos simples pueden ser, además, de dos tipos: constantes y variables. Las 
constantes están formadas por letras (o letras y el guión, si se unen pala- 
bras) formando «nombres» o por números, con o sin decimales. En los 
ejemplos anteriores, la-casa, el-río y la-colina son nombres compuestos (o 
sea, elementos simples y constantes). Los elementos compuestos, a su vez, 
están formados por otros elementos y se llaman listas. Una lista es un con- 
junto de elementos (elementos simples o listas) separados por blancos y en- 
cerrados entre paréntesis. Se admiten, por tanto, listas que contienen lis- 
tas. Se admite, asimismo, la lista vacía «()». La siguiente lista tiene cuatro 
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Simples (sólo letras) 


Nombres 
Compuestos (letras y guión) 


Constantes : 
Enteros 
Números f Decimales 
Exponenciales 


Simples 


Elementos 
Variables (x, y, z, X, Y, Z, x1, x2, ..., Y1, Y2, etc.) 
Compuestos = listas (formados por elementos simples o listas) 


(La lista vacía = ()) 
Fig. 4. Tipos de elementos. 


elementos: una constante numérica, una variable, una lista formada por 
dos constantes y una variable y la lista vacía 


Las frases compuestas se construyen ligando varias frases simples. Las 
conectivas lógicas utilizadas en PROLOG son el condicional «if» (es decir, 
«si» condicional), la conjunción «and» o «éz» (en castellano es «y») y la ne- 
gación «not» (que se corresponde con el castellano «no»). También está 
prevista la utilización de la disyunción «or», pero en una primera aproxi- 
mación no es necesario su uso (por lo demás, de sintaxis un poco más com- 
plicada), pues en vez de poner dos frases simples unidas por «or» se con- 
sigue, generalmente, el mismo efecto incluyendo las dos frases: en su pro- 
ceso de búsqueda de soluciones el analizador de PROLOG examinará la 
una y después la otra aceptando la afirmación correspondiente si se cum- 
ple cualquiera de ellas. 

La estructura general, por tanto, de una frase será la que se muestra en 
la figura 5; en ella aparecen varias frases simples, un condicional y dos con- 
junciones. Aparte de estos elementos, también podría aparecer la nega- 
ción, como en 


PPP 


(¿MAYOR-OUE 25 it not 25 LESS X and not 25 EO > 
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—_—_—_—_—_———— FRASE COMPUESTA ———NNNNNNNNN>A> 


FRASE SIMPLE FRASE SIMPLE FRASE SIMPLE FRASE SIMPLE 


e es _——— 


| 


x tía de y if x es mujer and xhermana dez and z madre de y 


a HQ HQ 


CONDICIONAL CONJUNCION CONJUNCION 


Fig. 5. Estructura de una frase compuesta. 


donde LESS (con mayúsculas precisamente) es una palabra predefinida 
que significa «menor-que» y EQ representa la igualdad (veremos con de- 
talle más adelante estas palabras predefinidas del PROLOG). 


== Tipos de notación 


Las frases del programa se pueden escribir en varias formas (mante- 
niendo su significado). Se utilizan tres tipos diferentes de notación: prefi- 
ja, infija y posfija. 

En los anteriores ejemplos hemos utilizado la notación «infija»; es de- 
cir, la relación aparece entre los sujetos detrás del primer elemento u ob- 
jeto y antes de los restantes, «la-casa está-entre el-río la-colina». En esta fra- 
se aparece la relación «está-entre» que vincula tres elementos: la-casa, el- 
río y la-colina. Esta notación es especialmente clara en los casos de rela- 
ciones con dos elementos: «la-casa está-a-la-derecha del-río». 

Pero esto mismo se podría haber escrito en notación prefija (la rela- 
ción o predicado se pone delante y los elementos detrás, como una lista; 
es decir, entre paréntesis y separados por espacios). Así podíamos haber 
escrito 


No) 


2 


Se puede utilizar cualquiera de estas notaciones, y en cada caso elegir 
la que resulte más clara, o se puede escribir (lo que es más usual) habi- 
tualmente en forma prefija. Esta notación (sin paréntesis) es la usada en 
micro-PROLOG, cuando no se utiliza SIMPLE. 


Construcción de una base de hechos 


Los anteriores elementos descritos son suficientes para construir un 
sencillo programa en micro-PROLOG, pero debemos ver ahora cómo in- 
troducirle los datos al ordenador y cómo manejarlos (con ayuda del tra- 
ductor adicional SIMPLE). 

Para el manejo de la base de hechos (conjuntos de frases que constitu- 
yen el programa PROLOG) se dispone de las siguientes órdenes: «add» 
(añade), «accept» (acepta), «delete» (borra), «kill» (elimina), «edit» (edita) 
y «list» (lista). 

Las dos primeras sirven para ir creando la base de conocimientos: en 
efecto, cuando cargamos PROLOG en el ordenador y nos da el mensaje de 
aviso (el «prompt» €.) cargando después el programa traductor SIMPLE 
(que vuelve a dar el prompt «.), podemos decir 


y esta frase («Segovia está-en Castilla-León) quedará incorporada a nues- 
tra base de hechos. A continuación introduciremos otra frase 


Si, por el contrario, queremos introducir varias frases semejantes uti- 
lizaremos «accept» (acepta) para decirle que «nos acepte» varias frases 
acerca de una misma relación. Por ejemplo, 


con lo cual a partir de ahora utilizará como nuevo prompt «está-a-la-dere- 
cha-de.», y podemos introducir varias frases, así: 


> arecha-de 
Acrecna-a 


prompt, para pedir datos de otra nueva frase, recordando de paso la rela- 
ción que estamos tratando en este momento. Con la palabra «end» (final) 
concluimos el proceso de la instrucción accept. 

Si, una vez que hayamos cargado nuestra base de hechos, queremos sa- 
ber qué hay en ella (para su corrección o simple curiosidad) no tenemos 
más que indicarle al traductor 


es decir, «lista todo» y nos dará un listado de toda la base de hechos 


Segovia está-en Castilla-León 
Eovia Esta-EHn Lastitta-LEOnN 


a a 
Felipell hie-rev 
pit ua- 10) 


la-casa está-entre el-ríio la-ca] 
= ecsta-Cintre e€l1- 110 1a-colina 


actás AAA A PP o 
esta-a-1a-derecna-de (Luis Antonio) 


Si, por el contrario, queremos listar únicamente las proposiciones que 
contengan la relación «está-a-la-derecha-de», escribiremos 


y obtendremos la siguiente relación: 


A A O O A e e 
esta-a-la-derechna-de (la-casa el-r10) 
O o A A A A O A 
esta-a-la-derecha-de (Luis Antonio) 


A AN A A 
está-a-la-derecha-de (Iglesia Avuntamiento) 
e A 


El listado que se obtiene cuando se le pide una lista completa (list all) 
aparece con todas las afirmaciones referentes a una relación agrupadas y 
en el orden en que han sido introducidas. 

Este tipo de listado es de mucha ayuda para la utilización de otra for- 
ma que puede adoptar una frase con «add»: si queremos añadir una frase 
dentro del grupo de las que tienen la relación «está-a-la-derecha-de», pero 
en la tercera posición (pasando, por tanto, la frase que teníamos en terce- 
ra posición a la cuarta) podemos escribir 


lA? fellciehilla estára-la-derecha-de el-miato) 
ada 3 (elr-cucnmiio esta-a-ta-aderecna-ae el-pDiato) 


de tal modo que si ahora hacemos 


A PP a 
está-a-la-derecha-de (la-casa el-río) 
Jpartasda Ci-110) 


e. 
está-a-la-derecha-de (Luis Antonio) 
MIS ARLONIO ) 


está-a-la-derecha-de (el-cuchillo el-plato) 
jerecha-de (el-cuecnitio el-plato) 


2 22de (Tolesia Avwintamienta. 
aaerecna-de (1g1esia Ayuntamiento) 
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Si deseamos eliminar frases de la base de hechos, podemos utilizar uno 
de los dos comandos siguientes: delete o kill. 

El primero de ellos, «delete» (borra) suprime una sola frase de la base 
de conocimientos, y el otro, «kill» (elimina), suprime todas las proposicio- 
nes que haya en la base de datos con la relación que se le indica. 


Por ejemplo, si decimos 


eliminará (en ambos casos igual) la tercera frase que hay en el grupo de 
las que tienen la relación «está-a-la-derecha-de». 


Si, por el contrario, decimos 


se eliminarán las cuatro frases que hay en ese grupo, de modo que un «list 
all» después dará como resultado, solamente: 


Por último, si lo que queremos es modificar una frase, disponemos de 
una palabra adicional que es «edit» (editar); se usa con el nombre de la re- 
lación en cuyo grupo está la frase que queremos cambiar y el número de 
orden dentro de ese grupo. Así, si antes de hacer el «kill» que acabamos 
de indicar (o una vez restaurada la base de datos) tecleamos 


No) 


6 


aparecerá en la pantalla la frase 


Almacenamiento y recuperación de datos 


Pero la base de hechos anterior (ya escrita y depurada) queremos guar- 
darla para su posterior utilización: debemos escribir la primitiva «save» 
guarda) con el nombre del fichero donde queremos que se almacene 
nuestra base de conocimientos. De este modo, 


us 


guardará todo el contenido actual de la base de conocimientos en el fiche- 
ro «nuevo-fich». 

En sentido contrario, para volver a cargar el fichero en el área de tra- 
bajo, escribiríamos 


es accesible mediante el argumento «dict». Si escribimos 


No 
XQ 


aparecerá un listado de las relaciones que hemos utilizado: 


está-en dict 

fue-rey dict 

está-entre dict 
está-a-la-derecha-de dict 


de modo que cada relación tiene a la derecha la palabra «dict»: podemos 
pensar que dict es como una propiedad (en notación posfija). De hecho, 
se puede manejar como una relación más y tiene, por tanto, sentido escri- 
bir 


delete dict 2 
o bien 


delete (fue-rey dict) 


== Utilización sencilla de los conocimientos 


Hemos visto hasta ahora cómo construir y almacenar una base de he- 
chos. Veamos ahora cómo utilizarla. Para hacer preguntas a la base de co- 
nocimientos (es decir, extraer información de ella) disponemos de cuatro 
primitivas adicionales: «is» (es), «all» (todos), «wich» (cuál o qué) y «one» 
(uno sólo). 

La utilización de estas primitivas es bastante semejante al uso que se 
hace de ellas en el lenguaje natural. La primitiva «is» puede adoptar dos 
formas: con constantes o con variables. Una pregunta del primer tipo sería: 


is (Segovia está-en Castilla-León) 
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(que recibirá la respuestas YES, puesto que esa afirmación está en nuestra 
base de hechos). Una pregunta con variables puede ser 


is (Segovia está-en X) = 


que tendrá también la respuesta YES, pues hay una relación que se ade- 
cúa a ese esquema, una vez sustituido X por el valor «Castilla-León». 

También se puede preguntar, no si existe una afirmación dada o no, 
sino para qué elemento se cumple la relación: es decir, preguntar «qué ele- 
mento X cumple que X está-en Castilla-León» o bien «qué X hay tal que 
X está-en Castilla-León» y en micro-PROLOG: 


wich (X : X está-en Castilla-León) 


a lo que el intérprete responderá: 


Segovia ] - == 
No (more) answers == - : 


dando el elemento que cumple la proposición propuesta (es decir Sego- 
via) y añadiendo «No (more) answers» (No —más— respuestas disponi- 
bles). Si hubiera varias respuestas, se darían todas las que cumplen la con- 
dición. 

Otro modo de hacer la pregunta es utilizar la primitiva «all» (todos) 
que es equivalente a «which»: 


all (X : X está-en Castilla-León) 


o bien sustituir la pregunta por otra que comience por la primitiva «one» 
(uno sólo), que produce el mismo efecto que «all» pero sólo da una res- 
puesta (la primera que encuentra) y pregunta si se quiere seguir: si se le 
contesta afirmativamente continuará la búsqueda; en caso contrario con- 
cluye. 

Naturalmente, puesto que el(los) argumento(s) de la pregunta es(son) 
una proposición de las que tenemos o podemos tener en la base de he- 
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chos, con o sin variables, se pueden hacer preguntas más sofisticadas me- 
diante las conectivas lógicas (como se describió al presentar las frases sim- 
ples de la base de conocimiento). Así se puede preguntar: 


A A A AA A e a o. 
wicntX-X esta:entre el-río la-colina £ 
AAA A A AAA 
cCestáa-la-derecha-de el-ri5) 
> CFI) 


O bien, 


Además, se dispone de dos palabras primitivas muy útiles en las pre- 
guntas: «defined» (definida) y «reserved» (reservada), que se refieren a esas 


la respuesta sería NO, pues «está-en» no es una de las palabras reservadas 
(primitivas) de micro-PROLOG. Por el contrario, respondería YES si le pre- 
guntásemos: 


pus 


(010) 


El argumento «dict», ya conocido, puede ser utilizado en las preguntas 
para saber si tenemos una relación en el diccionario o no. La pregunta: 


obtendría una respuesta YES. Por el contrario, 


Inclusión de reglas 


Toda la labor realizada hasta ahora es básica, pero poco fructífera: el 


ples o compuestas (con sus relaciones correspondientes) vinculadas por 
«if». Por ejemplo, podemos establecer: 


Con esto estamos marcando o definiendo una propiedad general que 
permitirá al sistema obtener conclusiones que no se le hayan dado, pero 
que sean deducibles (lógicamente) de los datos que se le han facilitado. 
Por ejemplo, si hubiéramos introducido la regla anterior, de la afirmación 
«la-casa está-a-la-derecha-de el-río» se podría deducir «la-casa está-entre el- 
río la-colina», y no hubiera sido necesario teclear dicha aseveración (o si 
no disponíamos de ella, la hubiéramos podido obtener). 
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El conjunto de hechos y reglas de inferencia constituye un programa 
en PROLOG y se puede decir que la parte más «creativa» de él son preci- 
samente las reglas, por lo que es usual llamar a los lenguajes del tipo de 
PROLOG lenguajes «basados en reglas». 

Las reglas se introducen en nuestra base de conocimientos al igual que 
los simples hechos, mediante la primitiva «add», se eliminan con «delete», 
etcétera. 
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REFERENCIA DE PRIMITIVAS 


Hasta aquí hemos estado viendo la estructura general de un programa 


Además de éstas, existen en PROLOG otras palabras reservadas que se 
utilizan para Operaciones concretas (manejo de listas, realización de ope- 


Operaciones con números 


Para realizar operaciones aritméticas están disponible (al menos) cin- 
co primitivas en PROLOG: «SUM» (suma); «TIMES» (por, multiplicado por, 
producto); «LESS» (menor que); «INT» (entero) y «EQ» (igual). 

Aunque parezcan pocas funciones para el manejo de números, la flexi- 
bilidad de PROLOG hacen que sean suficientes y que el resto de herra- 
mientas que el lenguaje proporciona ayude en la programación de los 
cálculos; a pesar de que, desde luego, PROLOG no ha sido diseñado para 
el proceso de números, sino de otro tipo de conocimientos e informacio- 
nes (que suelen venir dados en forma literal, básicamente). 

Obsérvese, por otro lado, que las primitivas indicadas aparecen con le- 
tras mayúsculas; la razón es que estas funciones son primitivas de micro- 
PROLOG que SIMPLE pasa directamente al intérprete sin traducir (como 
sucedía con «add», «delete», etc.). 


La palabra SUM se define diciendo que es cierto: 


SUM (X Y Z) 
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si Z = X + Y. Es decir, la respuesta a: 


is (SUM (2 3 5)). 


será YES. 
Se puede utilizar también, con el mismo sentido, en preguntas como: 


Ahich (x: SUM(2 3 x)) 


que dará como resultado: 


A partir de esta primitiva SUM se pueden definir (por parte del usua- 
rio) otro conjunto de operaciones aritméticas que pueda necesitar. 


Por ejemplo, se puede introducir la regla: 


MASSUMA(X1 X2 X3 Z) IF SUM (X1 X2 Y1) £ SUM(Y1 X3 Y2) 
E SUM(YZ X4 2) 


Que define la suma de tres números. O bien: 


wnichtx*—SUM(x—1:25-3.73)) 


que da como resultado la diferencia entre 3.75 y 1.25, es decir: 
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También se puede definir de un modo general: 


Los números utilizados en PROLOG pueden ser enteros (positivos —que 
no deben llevar signo—, o negativos con signo), decimales o en coma flo- 
tante (una secuencia de dígitos decimales con su parte entera y su parte 
decimal seguida de la letra E (de exponencial) y un entero). 

Para las multiplicaciones se utiliza la primitiva TIMES, que se puede de- 
finir diciendo que será cierto: 


si sucede que z = x*y. Se pueden hacer preguntas del tipo: 


que dará como resultado: 


o bien, para realizar divisiones: 


que dará como resultado, naturalmente: 


a 
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Se puede, sin embargo, definir expresamente la división: 


105 


la respuesta será: 


YES 


Por el contrario, en la forma de predicado binario se utiliza para gene- 
rar la parte entera de un número decimal: 


is(-3.25 INT x £k x EQ -4) 


dará como resultado: 


YES 


y la expresión: 


whichíx: 3.25 INT x) 


producirá la siguiente respuesta: 


== Manejo de listas 


Tal como dijimos en su momento, una lista es una sucesión de elemen- 
tos separados por blancos y encerrada entre paréntesis. La lista puede es- 
tar vacía, (), o puede contener, a su vez, otras listas como elementos de ella: 


(x 2.25 a (2 x) (5 X Y)) 


Cada lista hay que considerarla como un elemento en el interior de 
otra lista o como argumento de alguna función. Dentro de cada lista es útil 
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distinguir en numerosas ocasiones el primer elemento de la lista (llamado 
«cabeza» de la lista) del resto de los elementos que en ella aparecen (resto 
o «cola» de la lista). Con el fin de precisar estos detalles se utiliza la ex- 
presión (xly) para representar a una lista cuya cabeza es «x» y cuya cola 
es «y». Por tanto, si estamos considerando la lista (a b c d), la asignación 
de valores que realizará PROLOG para (x!ly) es: x es el elemento a; y es la 
lista (b c d). 

La barra de separación, |, se suele leer «seguido de», de tal modo que 
se acepta la expresión (x y | z) para representar una lista formada por los 
elementos x e y «seguido de» otro elemento z (que puede ser a su vez una 
lista). Como además el elemento z puede ser la lista vacía, la expresión an- 
terior representa a todas las listas formadas al menos por dos elementos. 

En ocasiones, en vez de la barra, |, se escribe una a modo de barra par- 
tida formada por dos puntos alargados, :. 

Es importante distinguir la lista como una unidad, de los elementos que 
la componen. Por ejemplo, en las expresiones: 


Luis es-de Familia-Lopez 

Juan es-de Familia-Lopez 

Carmen es-de Familia-Lopez 

(Ramon Juan) es-de Familia-Lopez 

(Maria (Carmen Luis)) es-de Familia-Lopez 


vemos que la relación «es-de» admite un sujeto que sea unitario y una lista 
(incluso en el último caso una «lista de listas»). Si preguntamos: 


is (Juan es-de Familia-Lopez) 


la respuesta sería YES, pero si la consulta es: 


is (Ramon es-de Familia-Lopez) 


la contestación será NO, mientras que obtendremos YES al preguntar: 


is((Ramon Juan) es-de Familia-Lopez) 
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Si preguntamos: 


y el sistema contestará con las familias (en nuestro caso sólo tenemos a la 
familia-López) a las que pertenecen elementos formados por dos elemen- 
tos. O bien introducir: 


O sea, elementos de la familia-López que se adecúen al esquema (X1 
X2). (Obsérvese que la primitiva EQ sirve para comparar listas igual que 


números.) La respuesta sería: 


Si la pregunta es: 
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(estamos preguntando por listas que tengan, concretamente, la estructura 
dada (X1 (X X2)); es decir, dos elementos el segundo de los cuales es, a 
su vez, una lista de dos elementos). 

O podemos querer obtener, por ejemplo, el primer elemento (cabeza) 
de la lista que está en segundo lugar en las listas de elementos que perte- 
necen a la familia-López, sin saber la longitud de esta segunda lista; la con- 
sulta sería, en este caso: 


el tercero la lista resultante; así: 


10 


No) 


significa que Z es la concatenación de la listas X e Y. Concretamente: 


append ((Ramon Juan) (Teofilo) (Ramon Juan Teofilo)) 


será verdad. 
Se puede utilizar en preguntas: 


is (append ((Ramon Juan) (Teofilo) (Ramon Juan Teofilo))) 
obtendrá la respuesta YES. Mientras que: 


all (X : append ((Ramon Juan) (Teofilo) X) 
tendrá como respuesta: 
(Ramon Juan Teofilo) 


Se puede añadir un elemento «César» en la cabeza de la lista anterior: 


all (X : append ((Cesar) (Ramon Juan Teofilo) X) 


dando: 


(Cesar Ramon Juan Teofilo) 


(Obsérvese que «append» maneja listas, por lo que hemos tenido que ha- 
cer César lista, para incluirlo en append como (César)). 
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Incluso, se puede usar «append» para descomponer listas: 
all (X : append ((Cesar) X (Cesar Ramon Juan Teofilo))) 


dará como resultado la «cola» de la lista que aparece en tercer lugar en 
«append»: 


(Ramon Juan Teofilo). 


-  RECURSION Y OTRAS TECNICAS 


- Tteración y recursión 


En los ejemplos anteriores hemos visto cómo examinar la «cabeza» de 
una lista y detectar o escribir que esa cabeza está formada por un solo ele- 
mento o por dos, tres..., etc. Sin embargo, nos queda detrás una «cola» de 
lista que, por ahora, no sabemos manejar bien. Por otro lado, tampoco po- 
demos saber cuántos elementos tiene una lista. 

Para realizar esta tarea es necesario utilizar un proceso iterativo de aná- 
lisis: es decir, un proceso paso a paso que vaya «separando» cada elemen- 
to de la lista. 

Por ejemplo, si queremos averiguar todos los individuos que pertene- 
cen (relación «es-de») a la «familia-López» independientemente de que es- 
tén como tales individuos aislados o dentro de una lista habría que hacer 
una pregunta del tipo: 


all (X :X es-de Familia-Lopez) 


que nos dá todos los elementos individuales de la relación «es-de», pero 
también: 


all (X : (X X1) es-de Familia-Lopez) 
all (X : (X2 X) es-de Familia-Lopez) 
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y así para todo el tipo de listas que pueden aparecer en la base de hechos. 
Para evitar esto (normalmente, incluso, ni conocemos cuáles son las di- 
versas estructuras de lista en juego), deberíamos hacer un examen iterati- 
vo de una lista genérica donde observemos cada elemento para ver si cum- 
ple la condición correspondiente. Un problema semejante surge cuando 
se quieren «contar» los individuos de una lista; teóricamente es fácil: se 
toma el individuo que sea la «cabeza» de la lista y se anota uno; se toma 
después la cola de la lista como nueva lista, y se vuelve a separar la cabeza 
añadiendo uno a la cuenta que llevamos; se vuelve a tomar como lista base 
la cola resultante y se vuelve a separar la cabeza anotando una unidad más, 
etcétera. Sin embargo, este proceso genérico debe ser programado como 
una actividad iterativa (programar un paso genérico que se repite para to- 
dos los elementos de la lista). En PROLOG no existe predefinida ninguna 
estructura de control que realice esta tarea, como es usual en la mayoría 
de los lenguajes (bucles DO, FOR, etc.) y es necesario programarlo. 

Se suele utilizar una técnica de recursión para resolver estas activida- 
des iterativas. La recursión consiste básicamente en que en la ejecución 
de un procedimiento se llama, bajo unas condiciones concretas, al mismo 
procedimiento. 

Hay que tener cuidado cuando se diseña un proceso recursivo para que 
el programa no entre en un «bucle» infinito (la función se está llamando 
a sí misma constantemente), sino que esté adecuadamente controlado el 
final del proceso, y el bucle concluya. Por ejemplo, en el caso en que es- 
temos examinando los diferentes elementos de una lista (para controlar al- 
guna condición dada o simplemente para «contarlos») tomando elemento 
a elemento, se puede cerrar el proceso recursivo preguntando por la con- 
dición de que la lista restante sea vacía. 

Así, podríamos definir una función «longitud de una lista» (en inglés 
«length») mediante la regla: 


donde decimos que la longitud (length) de X es Y si la longitud de X2 (cola 
de la lista) es Z y resulta que Y = Z + 1; es decir, que la longitud de la cola 
resultante cuando se le separa el primer elemento de cabeza. Aún se pue- 
de cóndensar más esta definición escribiendo: 


donde se ha separado, en la lista X cuya longitud queremos averiguar, la 
cabeza (X1) de la cola (X2). Esta definición es un caso típico de recursión, 
pues para definir la «length» de X es necesario antes «calcular» la «length» 
de su cola (X2) y sumarle una unidad; pero para el cálculo de la longitud 
de X2 habrá que aplicar, de nuevo, la misma definición añadiendo una uni- 
dad a la longitud de la cola de X2 (pongamos que sea X3), y así sucesiva- 
mente. Sólo existe una pequeña dificultad en la regla que estamos mane- 
jando y es que no está previsto un control de terminación del proceso re- 
cursivo: cuando la lista cuya longitud haya que calcular (después de un nú- 
mero determinado de pasos de iteración) sea la lista vacía, al ir a calcular 
la «cola» de la lista, se producirá un error. Para evitar este problema (¡pro- 
blema eterno de los procesos recursivos!) hay que definir, aparte, la lon- 
gitud de la lista vacía (que parece normal definirla como cero). Escribire- 
mos, por tanto: . 


Ahora, en cada fase del «cálculo de longitud» de una lista o sublista em- 
pezará el intérprete «procesando» la primera línea: si la lista no es vacía, 
pasará a la segunda línea; si la lista es, precisamente, la lista vacía, le asig- 
nará longitud O y avanzará al siguiente paso. 


De este modo, si introducimos la expresión: 


el intérprete verá que la lista dada (M1 (M2 M3) M4) no es vacía y realiza- 
rá la «identificación» de esta lista con el «esquema» dado en la segunda ex- 
presión haciendo X1 igual a M1 y X2 igual a ((M2 M3) M4). (Este proceso 
se llama «unificación»). Intentará entonces calcular Z como longitud de 
X2 y encuentra que no «sabe» la longitud de ((M2 M3) M4), por lo que 
deja sin evaluar este valor (provisionalmente queda pendiente la asigna- 
ción de valor para este primer Z obtenido; lo llamaremos Z1). A continua- 
ción, comprueba que la nueva lista (la «cola» X2; es decir ((M2 M3) M4) 
no es vacía y aplica la «definición» de longitud haciendo X1 igual a (M2 
M3), cabeza de la lista, y X2 igual a (M4), cola de la lista. Tampoco sabe 
la longitud de (M4), por lo que dejará sin evaluar una nueva longitud (Z2). 
Aplica de nuevo la «definición» tomando X1 igual a M4 y X2 igual a la cola 
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resultante que es la lista vacía. La longitud de esta cola (Z3) no la conoce 
y vuelve a aplicar la definición. Pero ahora la lista que maneja es ya la lista 
vacía, por lo que asigna como longitud de esta lista el valor 0. Así, pues, 
ahora sabe que Z3 =0 y, por tanto, según las expresiones de SUM que ha 
ido dejando pendientes, asignará valores Z2 =Z3+1=1;Z1=Z2+1=2 
y, por fin, Y = Z1 + 1 = 3, devolviendo como valor de Y el número 3. 


Este proceso de llamadas recurrentes a sí misma de la función «length» 
es un procedimiento usual utilizado en la programación en PROLOG, y es 
enormemente potente: sólo hay que tener cuidado con establecer adecua- 
damente la condición de terminación del proceso. 

Es usual que la primitiva «length» aparezca definida en el intérprete de 
PROLOG, pero si no es así, puede usted introducirla mediante la defini- 
ción dada anteriormente. 

Del mismo modo que la primitiva «length» se puede definir la primiti- 
va «append» (de la que ya hemos hablado), si en su PROLOG no está in- 
cluida. El resultado de unir (append) una lista X con otra Y para dar la lis- 
ta Z es igual que si tomamos el último elemento de X y lo unimos con Y 
y al resultado de esa unión le anteponemos los restantes elementos de X: 
por ejemplo: 


que es la consecuencia de unir X (es decir, (M1 M2 M3)) con Y (o sea, 
(M4 M5)). Pero el proceso lo podemos pensar como si tomamos el último 
elemento de X (M3) y lo unimos con Y para dar (M3 M4 M5) y al resulta- 
do le ponemos delante los elementos suprimidos en X, es decir (M1 M2). 
Y también para hacer esta última unión, tomar el último elemento (M2) y 
unirlo con el resto (M2 M3 M4 M5) anteponiendo después el elemento su- 
primido (M1). Todo este proceso lo podemos expresar mediante una defi- 
nición (recursiva) de la primitiva «append»: 


En esta regla, se aparta la cabeza de X (es decir, X1) y se une el resto 
(X2) con Y para dar Z2. Pero para hacer este append (el de X2 con Y para 
dar Z2) habrá que volver a «separar» la cabeza de X2 y unir con Y el resto 
y así sucesivamente. Esto representa el proceso que hemos descrito antes, 
pero formulado al revés. Sólo queda establecer la condición de termina- 
ción del proceso. Esta conclusión se debe producir cuando en la lista que 
está en la posición X no quedan más elementos para unir con Y, es decir, 
cuando la lista X sea vacía. Obviamente la unión (append) de la lista vacía 
con una lista cualquiera Y dará como resultado la propia lista Y. El con- 


También se puede definir de modo recursivo la primitiva «belongs-to» 
(«pertenece a») que establece la propiedad de los miembros de una lista 
de «pertenecer a» ella. (Normalmente esta primitiva estará definida en su 
PROLOG, si no, puede usted introducirla. Naturalmente, si va usted a in- 
troducir estas primitivas, puede definirlas con los nombres en castellano: 
«es-de-longitud» o simplemente «longitud» en vez de «length», «une» en lu- 
gar de «append», «pertenece-a» por «belongs-to», etc. Nosotros usamos los 
nombres ingleses por ser los más universalmente utilizados.) 

Para poder definir el concepto de «pertenece-a» para los elementos de 
una lista de tres elementos pondríamos sencillamente: «X pertenece-a Y 
si X es igual al primer elemento de Y (su cabeza) o igual a su segundo ele- 
mento (cabeza de su cola) o igual a su tercer elemento (cola de la cola)». 
Pero si no sabemos la longitud de la lista Y, tendremos que usar una ex- 
presión genérica y acudir a la recursión para, mediante un proceso itera- 
tivo, ir examinando la coincidencia del elemento X con los distintos ele- 
mentos de Y. Concretamente, esto se puede hacer definiendo: «X pertene- 
ce a Y si X es la cabeza de Y o bien si X pertenece a la cola de Y». La for- 
mulación de esta frase en PROLOG se realizará mediante dos relaciones 
alternativas: 


PROLOG responderá: 
_<—-<A<A<X<A<ÓK<á< K< A A<A<AAA<A<A << KK A >>> 


de acuerdo con la primera regla; y si pedimos más respuestas (recuérdese 
que «all» va dando las respuestas una a una) 


También se pueden definir recursivamente otras primitivas no utiliza- 
bles en el manejo de listas, sino en operaciones aritméticas: por ejemplo, 
la primitiva «factorial». 

Como el lector sabe, el factorial de un número entero «n» (se suele es- 
cribir n!) es el resultado de multiplicar «n» por «n-1», por «n-2», etc.; es 
decir, el producto de todos los enteros hasta el «n» inclusive. Además, el 
factorial de 1 es 1. Y se suele definir que el factorial de O es, también, 1. 
No podemos definir de un modo explícito el factorial de «n» multiplican- 
do los «n» primeros enteros menores o iguales a «n» (pues «n» puede ser 
cualquier número). Es necesario hacerlo de un modo iterativo formulan- 
do que el factorial de «n» es igual a «n» multiplicado por el factorial de 
«n—1». Es decir, si X1 es una unidad inferior a X, el factorial de X es igual 
a X multiplicado por el factorial de X1. O bien en PROLOG (diciendo que 
«X factorial Y» significa que Y es el factorial de X: Y = X!): 


Esta definición es válida para cualquier X menor que 1, pero producirá 
error para X = 1 (pues PROLOG no podría calcular el factorial de X1 en 
este caso). Hay, por tanto, que definir este valor (cerrando, de este modo, 
el ciclo de recurrencias que se produce al ir calculando los factoriales de 


116 


números cada vez una unidad menores, X1). La definición completa será, 
por tanto: 


Búsqueda bajo condiciones más complejas 


Aparte de las preguntas que podíamos realizar mediante las primitivas 
«is», «wich», «all»... que producían respuestas simples (un elemento cada 
vez), se puede conseguir que la contestación a una pregunta sea una lista. 
Esto sucede si se realiza la pregunta con la primitiva «isall» («es-todo»). La 
respuesta es una lista con todos los elementos que cumplen la condición: 
todas las respuestas que hubiéramos obtenido si hubiéramos hecho la pre- 
gunta con «all» puestas en forma de lista. Así, por ejemplo, la pregunta: 


pues el único elemento que cumple la condición de X1 descrita anterior- 
mente es «la-casa» y lo devuelve en forma de lista. Si la respuesta a la con- 
dición de X1 hubiera sido (con otra base de hechos): 


la correspondiente respuesta de «isall» sería: 


Naturalmente, «isall» se puede usar no sólo en preguntas, sino forman- 
do parte de reglas del programa. Por ejemplo: 


_—_—————_—_———————————————————————— 
iíÓ—_——_——_————————————————— SS 
== _—_——_——_———_—— AAA 
5D Padres d 


A A O A PF a 
£ 1isatll (41 ; A padre-de £1 QU 


AA A 
í madre-de £1) 


5 nn a a aa 
ar 
e 5 5 5 5 5 5 5 5 


Otra condición muy interesante es la que se construye con la primitiva 
«forall». El formato general de la condición «forall» es: 


donde condición1 y condición2 son dos condiciones simples o compues- 
tas (con la conjunción and, é: —o sea, «y»—). Hay que leer la frase anterior 
como «para todos los elementos que cumplen condición1 se cumple con- 
dición2». Por ejemplo, se puede definir el subconjunto de un conjunto 
dado del siguiente modo: 


| 


(forall X1 : 


ner! E the (] Y 
JOFall AL Ppertenece-a A tmen A1 pertenece-a 1] 


y a partir de esta definición establecer la siguiente: 


pa 
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Por otro lado, se pueden hacer preguntas más complejas que las esta- 
blecidas hasta ahora introduciendo junto a la condición ya definida (and, 
é2), la disyunción (0) y la negación (no). 


La disyunción (A o B) se formula como: 


(es decir, «bien A o B»). Como ya hemos comentado, es equivalente nor- 
malmente a poner ambas condiciones sucesivamente: 


puesto que PROLOG evalúa «la una o la otra» indistintamente (y sucesiva- 
mente). Así, es equivalente escribir: 


A PPP E APP o 
Xx FEO Carmen ¡11 (X X1) es-de Familia-Lópvez 
SI Ml A o A DALIA MAA 


V ENT 
CEO Carmen ll (X2 (X X3)) es-de Y «£ 
ENSALADA 1 1 14M ADJ] ESTU E 


que escribir: 


También se pueden establecer preguntas complejas introduciendo la 
negación mediante la partícula «not». La condición «not» se cumplirá si 
no se cumple la correspondiente condición afirmativa formulada según las 
reglas descritas. Así, se puede escribir: 


W1CN (LA : Cartost es-abuelo-de AG 
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que pregunta por los nietos de Carlos I que no fueron gobernadores de los 
Países Bajos. 


Control de la búsqueda de soluciones 


Ya hemos comentado cómo PROLOG realiza la búsqueda de solucio- 
nes, para cualquier pregunta que se le propone, siguiendo una rama del 
árbol y volviendo hacia atrás (backtracking) hasta el último nudo examina- 
do, para seguir después por otra rama, volver atrás, etc., hasta encontrar 
todas las soluciones. Esta técnica tan fructífera en general, puede ser su- 
mamente tediosa en ocasiones. Si conocemos la estructura de la base de 
hechos que manejamos o las condiciones en que se va a producir la bús- 
queda, podemos controlar este proceso de «vuelta atrás» mediante el sím- 
bolo «/». En efecto, esa barra inclinada impide la continuación del proce- 
so de búsqueda hacia atrás. Se utiliza como una condición simple más den- 
tro de cualquier condición compleja y unida, por tanto, al resto de la frase 
mediante una conjunción («4»): cuando PROLOG, en su evaluación de so- 
luciones encuentra dicho símbolo detiene el proceso de búsqueda hacia 


DIALECTOS Y VERSIONES 


Existen numerosas versiones de PROLOG e, incluso, variantes del len- 
guaje (dialectos y derivados), pero vamos a presentarlos reunidos en tres 
grupos: 


a) Por un lado, están las diferentes versiones «oficiales» de PROLOG. 
Este lenguaje ha sido soportado básicamente, en sus comienzos, y apoya- 
do por el grupo del profesor Colmerauer en la Universidad de Marsella- 
Luminy. Han ido produciéndose en ese grupo, o en otros que trabajan re- 
lacionados con él, numerosas y sucesivas mejoras al lenguaje. Actualmen- 
te está disponible ya la versión 2 del PROLOG II para ordenadores VAX, 
Mackintosh e IBMPC. Esta versión ha sido desarrollada en Pascal, lo que 
le da flexibilidad (el propio usuario puede modificar y ampliar las carac- 
terísticas del lenguaje) y portabilidad. Según la profesora García Serrano 
y su grupo (Facultad de Informática de Madrid), las características básicas 
del lenguaje son: 


Permite la continuidad entre la forma de entender y de especificar los 
problemas para su programación, no obliga al determinismo y dispone de 
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variables generalizadas. Además, la unificación de términos es automáti- 
ca, así como la estrategia de búsqueda primera en profundidad con back- 
trackting al anterior punto de elección. La computación es dirigida por el 
objetivo y el control se realiza con metarreglas y predicados definidos. 

Entre los predicados definidos del PROLOG Il v2 se destaca el predi- 
cado «freeze», que permite retardar la ejecución de objetivos y el predica- 
do predefinido «dif», que presenta la particularidad de que no es evaluado 
hasta que sus argumentos han sido unificados. 

Con respecto a las estructuras de datos aparece en esta implementa- 
ción además de las listas, la estructura de árbol (infinito o no) con un có- 
digo interno económico que permite parametrizar predicados, agrupar ob- 
jetivos o definir listas de longitud determinada. 

Entre las utilidades del sistema se encuentran predicados que comuni- 
can con el sistema operativo, un editor de línea, predicados de modifica- 
ción y estructuración de reglas en los llamados «mundos», predicados de 
inserción y eliminación de reglas (todos ellos utilizables desde el sistema 
PROLOG o desde el programa). Permite, además, la comunicación con 
otros lenguajes (Pascal, Basic, Fortran). 

Esta versión de PROLOG es exigente tanto en tiempo como en memo- 
ria, pero se espera que con técnicas de paralelismo, compilación u otras, 
se consiga una mayor eficiencia en su ejecución. 

Se ha utilizado para realización de prototipos de Sistemas Expertos de 
tipo medio (< = 500 reglas) y su operación ha sido interesante para esta 
misión, así como para modelos de comprensión del lenguaje natural con 
el método de las gramáticas de metamorfosis definidas por Colmerauer. 


Incluimos a continuación tres programas pequeños en PROLOG para 
que puedan observarse las escasas diferencias existentes con los progra- 
mas vistos hasta ahora. 

La definición de «append» en PROLOG será (compárese con la versión 
ya presentada de la misma relación para micro-PROLOG): 


en donde aparecen dos expresiones: la primera define el resultado de unir 
la lista vacía a otra lista cualquiera. La segunda reduce la concatenación 
de dos listas [X | L1] y L2 a la concatenación correspondiente de la pri- 
mera lista sin su cabeza, con la segunda lista. 
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El cálculo del discriminante de una ecuación de segundo grado se pue- 
de hacer mediante la expresión: 


mn Pe Q Q5) MP7 n a 
mult(4,S1,$52), add(SZ, D, Balcuad) 
A A A A A AA A AAA 


donde Balcuad es el cuadrado de B; S1 es un subtotal resultado de multi- 
plicar A*C; S2 equivale a 4*A*C y D se obtiene como aquel número que 
hay que sumar a S2 para obtener B, es decir, B - 4*A*C. 

Por último, podemos examinar el programa que el propio Colmerauer 
presentó en el congreso de IJCAI-83 para resolver el conocido criptogra- 
ma SEND + MORE = MONEY, donde cada letra puede representar un dí- 
gito cualquiera (de O a 9) y la asignación de valores tiene que ser tal que 
la suma sea correcta. El programa consta de tres partes: la primera ense- 
ña, sencillamente, a sumar (los números se representan con un punto por 
medio: por ejemplo, 15=1.5; 9=0.9). La segunda define la secuencia de va- 
lores sin repetición (eliminando las letras duplicadas). Con estas definicio- 
nes se puede pasar a la tercera parte, donde se hace realmente el cálculo 
de la solución. Si se pregunta después por «resultado (X,Y,Z)», la respues- 
ta será X=9.5.6.7; Y=1.0.8.5; Z=1.0.6.5.2, como el lector habrá calcula- 
do ya. 


Primera parte 


4 
¡In-Trepeticion (! 


— fu vacía) e 
quita (u, vacia) 
canoas. 


Tercera parte 


más-uno (x.r.u,) 
(ayi 


(Se han utilizado r,, r,, r, y r¿ para representar los «acarreos» —arrastre de 
una unidad o de ninguna para la suma parcial siguiente cuando la suma 
de dos dígitos individuales rebasa la decena—.) 
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b) Por otro lado, existen numerosas versiones del lenguaje PROLOG 
que se ofrecen independientes o integradas en otros conjuntos de progra- 
mación o entornos más complejos. 


QUINTUS PROLOG 


Versión desarrollada por Quintus Computer Systems, Inc., aporta bási- 
camente dos ventajas: una, más fácil manejo (para los angloparlantes) pues 
sus instrucciones se manejan con formatos parecidos al propio idioma in- 
elés, lo que lo aproxima a toda persona no versada en la nomenclatura de 
la lógica formal; y sus mecanismos de control incorporados que facilitan 
la creación cómoda de prototipos. Xerox ofrece una versión de QUINTUS 
PROLOG, mejorada en prestaciones gráficas, con sus estaciones de traba- 
jo de I.A., junto al INTERLISP y otras facilidades de desarrollo. 


QUTE 


Desarrollado en la Facultad de Ciencias de la Universidad de Tokio, es 
una amalgama de LISP y PROLOG. Es válida en QUTE cualquier expresión 
PROLOG y cualquier expresión LISP. Cada una de ellas es tratada por la 
parte correspondiente de QUTE, además, la parte LISP y la parte PROLOG 
se llaman una a otra recursivamente. 

Se ha implementado en un ordenador VAX bajo sistema operativo 
UNIX. 

Aunque en QUTE una expresión PROLOG puede contener, a modo de 
subexpresiones, una expresión LISP y viceversa, las expresiones simbóli- 
cas pueden jugar el doble papel de datos y programas, como sucede en 
LISP. Todas estas capacidades producen un lenguaje más claro y una ma- 
yor libertad de expresión y representación del conocimiento. 


ARITY/PROLOG 


Es una versión desarrollada por Arity Corp., básicamente para ordena- 
dores que trabajen bajo MS/DOS. Incluye acceso aleatorio a los archivos 
de datos y manejo de pantallas. Como dispone de una facilidad para ma- 
nejar memoria virtual, puede llegar a procesar aplicaciones de gran tama- 
ño. Por ello, es muy útil cuando se trabaja en ordenadores no grandes (IBM 
PC/AT, por ejemplo) pero con una gran RAM disk y disco duro de gran ta- 
maño. Dispone de. un compilador bastante eficaz y algunas otras caracte- 
rísticas sofisticadas de PROLOG como son la notación infija con preceden- 
cia de operador y las gramáticas con cláusulas definidas (DCG.) En la úl- 
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tima versión disponible (versión 4.0) permite la definición de varios «mun- 
dos» (particiones independientes de la base de datos) y, por tanto, admite 
definir en «mundos» separados el «código» y los «datos», lo cual es espe- 
cialmente útil si se manejan grandes espacios de memoria virtual, pues au- 
menta enormemente la eficiencia de proceso del sistema. 


TURBO PROLOG 


Ha sido desarrollado por Borland International Inc., autora de otros 
lenguajes «turbo» muy populares. Aporta una facilidad enorme de manejo 
mediante una presentación en pantalla a través de cinco «ventanas» y un 
conjunto cómodo y flexible de menús y comandos predefinidos. La sin- 
taxis de TURBO PROLOG es bastante diferente de la estándar de PROLOG 
y, por ello, más cómoda de manejar y leer. El programa en TURBO PRO- 
LOG se divide en diferentes secciones de declaración de los diversos ele- 
mentos (alguna de estas secciones son opcionales): sección de «dominios» 
donde se declaran las listas y tipos definidos localmente por el usuario; la 
sección de «dominios globales» permite que los tipos de datos en ella de- 
finidos sean utilizables por otros módulos de programa; la sección de «pre- 
dicados» define el tipo de los predicados locales y el tipo y número de los 
argumentos que cada predicado debe utilizar; la sección de («predicados 
globales» cumple la misma misión para los predicados accesibles desde 
otros módulos de programa; puede incorporarse una sección de «objeti- 
vo» (goal) para incluir un objetivo a alcanzar (esta sección es opcional, y 
puede omitirse para ir dando los objetivos en tiempo de ejecución, pero 
debe incluirse si se compila el programa); la sección de «base de datos» 
especifica los predicados a los que se van a añadir «hechos» en tiempo de 
ejecución; la sección de «cláusulas» contiene los hechos y reglas que for- 
man el cuerpo del programa. Contiene numerosos predicados predefini- 
dos y un conjunto muy cómodo de comandos para manejo de archivos. Su 
compilador es bastante eficiente, y los programas compilados son rápidos. 
Se le acusa de no ser un PROLOG clásico, sino ser casi un híbrido de Pas- 
cal y PROLOG (se le llama, un tanto despectivamente, «TURBO PASLOG»). 
Sin embargo, es muy cómodo de manejar y bastante flexible. A modo de 
ejemplo de la programación en este lenguaje que se está haciendo tan po- 
pular, damos la versión TURBO PROLOG de la definición del factorial, y 
la versión completa del programa de las «torres de Hanoi». 


Definición del factorial de un número entero 
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predicates 
factorial (n,f) 
= clauses 

factorial (1,1). 

factorial (N,Res) if 
N > and 
N1 = N-1 and 
factorial (N1,FacN1) and 
Res = N*FacNl. 


Las Torres de Hanoi 


DOMAINS 
TIME, ROW, COL, NUMBE = INTEGER 
PREDICATES 
-———hanoi( NUMBER ) 
-move(l NUMBER, NUMBER, ROW, ROW, ROW, COL, COL, COL) 
inform( NUMBER, NUMBER, ROW, ROW, COL, COL ) 
- makepolel NUMBER, NUMBER, COL) 
delay() dd(TIME) 
move_vert(COL,NUMBER,ROW,ROW) 
-move_horizon(ROW,NUMBER,COL,COL) 
- CLAUSES 
delay :- dd(100). 
dd(0):-!. 
-— dd(N):-N1=N-1,dd(N1). 
-———hanoi (N) :- 
: N<=13,!, 
VB=2+6*N,VH=3+N,CV=N, CM=3*N, CH=5*N, 
-STCOL=(79-6*N)/2, STROW=25-VH)/2, 
makewindow(1,7,7,“Hanoi”,STROW,STCOL,VH,VB), 
makepole(N,N,CV), 
-—move(N,N,0,0,0,CV,CM,CH), 
cursor (0,0), write(““Pulse una tecla””),readehar(—). 
hanoi(—):- write(“'máximo 13 disc'sin”). 
move(H,1,HA,_,HC,CA,-,CH):-!,INFORM(H,1,HA,HC,CA CH). 
move(H,N,HA,HB,HC,CA,CB,CC):- 
N1=N-1. 
HA1=HA+1, 
move(H,N1,HA1,HC,HB,CA,CC,CB), 
inform(H,N,HA,HC,CA,CC), 
HC1=HC+1, 
move(H,N1,HB,HA,HC1,CB,CA,CC). 
inform( H, N, H1, H2, C1, C2) :- 
C11=C1-N, C22=C2-N, NN-2'N, 
H11=H-H1, H22=H-H2, 
move_vert(C11,NN,H11,1), 
move_horizon(1,NN,C11,C22), 


126 


move_vert(C22,NN,1,H22). - == 
makepole(_,0,-):-!. = 


-—makepole(H, N,C): -HH=H-N pe N,HH,HH,C,C), NI=N-1, makepo- 
le(H,N1,0). 


-move_vert(_,-,H,H):-!. = 
move_vert(COL,SIZE,H1,H2):-H1<H2,!, /* mueve hacia arriba */ 

H11=H1+1, 
field_attr(H11,COL,SIZE, 112), 
field_attr(H1,COL,SIZE,7),delay,delay, 
move_vert(COL,SIZE,H11,H2). 

- o ,H1,H2): -H1>H2/! , /* mueve hacia abajo */ 

: =E 


field_attr(H11,COL,SIZE,112), 
= SIE ER = = 
== - move_vert(COL,SIZE,H11,H2). AZ - === 
-  move_horizon(-,-,H,H):-... - 
-—move_horizon(ROW,SIZE,C 1 ,C2):-C1<C2,!, /* mueve a la derecha */ 
-C11=C1+1, HH=C1+SIZE, = 
- : field_attr(ROW,HH,1,112), = a 
field_attr(ROW,C1,1,7),delay, - 
: -move_horizon(ROW SSIPEECEZ 
-move /¡SIZE,C1 ES -C1>C2,, /'mueve a la izquierda */ 
C11=C1=1, HF =C11+SIZE, 
_field_attr(ROW,C11,1. un = 
—field_ Es 


elay, 
move_horizon(ROW,SIZE,C C11,C2).. 
goal 
hanoi(6). 


c) Sacamos aparte del grupo anterior una versión muy popular de 
PROLOG desarrollada específicamente para ordenadores personales: el 
micro-PROLOG, que es la versión más extendida en este tipo de equipos 
(y que es la utilizada en todo este capítulo por entender que es la más ac- 
cesible al lector medio de este libro). La mayoría de las versiones existen- 
tes de micro-PROLOG incluyen un traductor adicional llamado SIMPLE: 
las palabras «add», «list», «if», etc., utilizadas hasta ahora, son comandos 
que SIMPLE traduce a la sintaxis estándar de micro-PROLOG. La sintaxis 
estándar de micro-PROLOG es más sencilla y compacta que la de SIMPLE, 
pero por ello mismo, más oscura y difícil de leer. Los conceptos básicos 
de proceso y las estructuras de programa son muy semejantes, por lo que 
ha sido útil utilizar SIMPLE en los ejemplos. Los comandos en micro-PRO- 
LOG se escriben siempre con mayúsculas (pero las variables pueden estar 
escritas con minúsculas). Como sabemos, en SIMPLE las palabras clave se 
escribían en minúsculas, excepto algunas (LESS, SUM, etc.) que tecleamos 
en mayúsculas precisamente porque son primitivas de micro-PROLOG que 
el traductor SIMPLE pasa al intérprete, sin más cambio. 
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Las reglas básicas de la sintaxis de micro-PROLOG (que difieren de la 
sintaxis de SIMPLE) son: 


— Los elementos constitutivos del lenguaje son los átomos y cláusu- 
las: un átomo es una aseveración básica de las que hemos llamado rela- 
ción o propiedad, con sus argumentos correspondientes; en micro-PRO- 
LOG desaparecen las notaciones infija, prefija o posfija y se escribe sim- 
plemente la proposición como una lista con el predicado (la relación) en 
cabeza y los argumentos detrás, todo entre paréntesis. Así, en vez de 


¡ODEFNaoc 
nes-de Familia=LCopb6ez 
€EOÁO A A A A A A A A A A A A A A 


es un átomo, mientras que 


' 


jua 
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es una cláusula unitaria («singulete», se llama a veces). Si la expresión que 
consideramos no es una aseveración simple, sino una regla de derivación, 
del tipo 


la conversión en cláusula de micro-PROLOG consiste en suprimir el «if» 
y cambiar a átomos las proposiciones simples que forman la frase. Así, la 
cláusula correspondiente será: 


donde aparece una lista formada por átomos entendiéndose que el prime- 
ro es la frase que se coloca delante de «if» y el segundo la proposición que 
se escribe detrás. Si la frase es más complicada, por ejemplo del tipo: 


que, como se ve, sigue siendo una lista en la que el primer átomo es la pro- 
posición que precedía al «IF» y el resto de átomos son las frases que esta- 
ban tras el «IF» suprimiendo, también, la conjunción «AND» (0 «éz»). 

— Algunas condiciones y primitivas más sofisticadas que se usan en 
SIMPLE tienen una «traducción» más compleja en micro-PROLOG: 


*either...or... se sustituye, simplemente, por el predicado OR con dos 
cláusulas (siempre entre paréntesis y separadas-por un blanco para formar 
—a su vez— otra cláusula). Así, una frase del tipo: 


se escribirá: 


ET VE E 
CALAAX3)7)89”00 Vte > 


donde aparece una cláusula formada por dos cláusulas (esta es la estruc- 
tura del if); la segunda de estas cláusulas está formada por el OR y dos cláu- 
sulas: una simple y otra segunda formada por una lista de dos cláusulas 
(que corresponde con la conjunción —and— de estas dos cláusulas). 


*not. Aparece escrita en mayúsculas, con una interrogación detrás y te- 
niendo como argumento a una cláusula; el conjunto se encierra entre pa- 
réntesis para constituir, a su vez, otra cláusula. 


Así, la frase 


* isall. Esta relación aparece como cabeza de una lista cuya cola está 
formada por la lista de respuestas, la lista de variables que han de cumplir 
las condiciones y la cláusula donde se expresan las condiciones (esta cláu- 
sula será una lista de cláusulas, si en la versión SIMPLE hubiéramos pues- 
to una condición compuesta formada por varias, relacionadas entre sí por 


cha=01 


scha=0€6 


* forall. Aparece (como sucedía con OR) con dos argumentos corres- 
pondientes a los dos conjuntos de condiciones. 


De este modo, la expresión de SIMPLE 


— Otras primitivas mantienen, prácticamente, su sintaxis: así, se usan 
igual que en SIMPLE las primitivas LIST, EQ, KILL, y, en general, la ma- 
yoría de las que hemos utilizado (en SIMPLE) con mayúsculas. 


— Para añadir y borrar cláusulas de la base de hechos, se usan ADDCL 
(en vezde«add») y DELCL (en vez de «delete»), pero con la misma sintaxis. 
Sin embargo, si lo que queremos es simplemente añadir una cláusula (sin 
colocarla en un sitio predefinido ni ninguna otra de las opciones más so- 
fisticadas que el «add» permite), se teclea sencillamente y micro-PROLOG 
la incorpora a su base de datos. 


— Las funciones de escritura disponibles son P y PP. La primera escri- 
be una frase (que aparece como cola de un átomo cuya cabeza es precisa- 
mente la función «P») y la segunda realiza la misma operación, pero ha- 
ciendo una «vuelta del carro» a continuación. 


Por ejemplo, 


escribirá la frase «El valor del diámetro es 5.2» si el valor de «X2» era 5.2, 
y quedará lista para seguir escribiendo en el mismo renglón, mientras que 
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escribirá la misma frase pero producirá, después, un salto al comienzo de 
la línea siguiente. 

Para introducir datos se usa la primitiva «R» que espera datos desde el 
teclado y los va asignando a las variables que se le han puesto como argu- 
mentos hasta asignar valor a todas ellas. Por ejemplo, se puede preparar 
una expresión del tipo «(R X)» para aceptar un dato y asignárselo a la va- 
riable «X». Se podría construir un diálogo del siguiente modo: 


donde la primera y la tercera líneas han sido tecleadas por el usuario, y la 
segunda y la cuarta han sido escritas por el intérprete de micro-PROLOG. 

— La interrogación se hace mediante la primitiva «?» (que equivale a 
«is» de SIMPLE) y la respuesta será éz (el propio «prompt» del sistema) si 
es YES o bien «?» (como respuesta de micro-PROLOG) si es NO. 

— Los comentarios se introducen con «/*». O sea, una cláusula que co- 
mience por «/*» no será evaluada por el sistema. Así, se pueden documen- 
tar los programas, y este capítulo podríamos cerrarlo (si fuera un progra- 
ma en micro-PROLOG) con el comentario: 


/* Fin del capítulo tercero 
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Libro en que se describen los lenguajes 
específicos para la «elaboración del saber» 
y los entornos de programación 
correspondientes. 


El conocimiento de estos lenguajes, 
además de interesante en sí mismo, es 
sumamente útil para entender todo lo que 
la Inteligencia Artificial supondrá para el 
futuro de la Informática y está 
significando hoy en día. 


